From bram at gawth.com Mon Mar 4 22:05:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] p2p-hackers meeting Message-ID: Since we don't all meet up in real life often enough, I'm organising a real-life p2p-hackers meeting this friday, at the metreon in san francisco. Well meet at 6pm by the food area, the seating section you have to walk up stairs to get to. I'll be there with a black eye (I just had surgery today) -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sat Mar 9 21:59:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] hackers meeting Message-ID: Yesterday's meeting went very well - me, burtonator, twitchkat, stevej, and tvoj all showed up, and chatted about various technical topics at length. I think next time we have one in sf it should be on a sunday starting at 2pm, what does everyone else think? -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From gwachob at wachob.com Sat Mar 9 23:12:02 2002 From: gwachob at wachob.com (Gabe Wachob) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] hackers meeting In-Reply-To: Message-ID: +1 On Sat, 9 Mar 2002, Bram Cohen wrote: > Yesterday's meeting went very well - me, burtonator, twitchkat, stevej, > and tvoj all showed up, and chatted about various technical topics at > length. > > I think next time we have one in sf it should be on a sunday starting at > 2pm, what does everyone else think? > > -Bram Cohen > > "Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > -- Gabe Wachob gwachob@wachob.com Personal http://www.wachob.com CTO, WiredObjects http://www.wiredobjects.com From lucas at worldos.com Sun Mar 10 17:41:01 2002 From: lucas at worldos.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] hackers meeting In-Reply-To: Message-ID: ...speaking of meetings etc, I've been hanging with a mini-group of p2p hackers in nyc, and others are welcome to join us. We've been doing the hang at alt.coffee on Ave A. On Sat, 9 Mar 2002, Bram wrote: > Yesterday's meeting went very well - me, burtonator, twitchkat, stevej, > and tvoj all showed up, and chatted about various technical topics at > length. From stevej at pobox.com Sun Mar 10 17:52:01 2002 From: stevej at pobox.com (steve jenson) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] hackers meeting In-Reply-To: Message-ID: Sounds great to me. -stevej On 3/9/02 11:11 PM, "Gabe Wachob" wrote: > +1 > > On Sat, 9 Mar 2002, Bram Cohen wrote: > >> Yesterday's meeting went very well - me, burtonator, twitchkat, stevej, >> and tvoj all showed up, and chatted about various technical topics at >> length. >> >> I think next time we have one in sf it should be on a sunday starting at >> 2pm, what does everyone else think? >> >> -Bram Cohen >> >> "Markets can remain irrational longer than you can remain solvent" >> -- John Maynard Keynes >> >> _______________________________________________ >> p2p-hackers mailing list >> p2p-hackers@zgp.org >> http://zgp.org/mailman/listinfo/p2p-hackers >> From burton at openprivacy.org Mon Mar 11 20:13:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] hackers meeting In-Reply-To: References: Message-ID: <871yeqh1aw.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bram Cohen writes: > Yesterday's meeting went very well - me, burtonator, twitchkat, stevej, and > tvoj all showed up, and chatted about various technical topics at length. > > I think next time we have one in sf it should be on a sunday starting at 2pm, > what does everyone else think? +1 - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ ...Remember that corporations are amoral. Not moral or immoral but amoral. They logically determine how to make the most money. They make decisions without regard to compassion or ethics, much like a computer. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8jYAnAwM6xb2dfE0RAgh3AJ42My9OagSEF8OhFjIiNN3UdYeruQCfdAWp mfxJqvTzrFlEi2fVvmFAPm0= =IPqJ -----END PGP SIGNATURE----- From justin at chapweske.com Tue Mar 12 10:51:02 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? Message-ID: <3C8E4DF6.2010700@chapweske.com> Does anyone have any good pointers to research on optimal replication strategies. By this I mean a quantification of how much a piece of content should be replicated depending on its file size, available disk space, and popularity of the content. I once read something about the "square root of its popularity" (whatever that means) as being the sweet spot for replication. I'm also curious how close systems like Freenet and Mnet come to this ideal. Thanks, -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From hal at finney.org Tue Mar 12 11:30:01 2002 From: hal at finney.org (hal@finney.org) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? Message-ID: <200203121930.g2CJUnr25833@finney.org> Justin Chapweske, , writes: > Does anyone have any good pointers to research on optimal replication > strategies. By this I mean a quantification of how much a piece of > content should be replicated depending on its file size, available disk > space, and popularity of the content. > > I once read something about the "square root of its popularity" > (whatever that means) as being the sweet spot for replication. I don't know of research on exactly this topic, but there is a general observation on popularity of items called Zipf's law. See for example http://linkage.rockefeller.edu/wli/zipf/. Quoting from there, "Zipf's law, named after the Harvard linguistic professor George Kingsley Zipf (1902-1950), is the observation that frequency of occurrence of some event (P), as a function of the rank (i) when the rank is determined by the above frequency of occurrence, is a power-law function P_i ~ 1/i^a with the exponent a close to unity." There are many phenomena which follow Zipf's law, including web pages and English words. Chances are the documents in a file sharing system would follow it as well. Under this law, if the most popular item gets N hits, the 2nd most popular item gets N/2 hits; the third most popular gets N/3 hits, and so on. Turning this into a replication strategy would probably depend on your goals. Do you want to be strictly driven by popularity, so that an item is replicated proportionally to how popular it is? Or do you want to guarantee storage for even unpopular items, perhaps allowing for some degradation in accessibility for the most popular items? Using the square root of popularity rank would seem to be a compromise between a straight Zipf law replication (which would replicate proportional to popularity ranking) and an even distribution where all documents are replicated equally. Hal Finney From lgonze at gonze.com Tue Mar 12 12:32:01 2002 From: lgonze at gonze.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? In-Reply-To: <3C8E4DF6.2010700@chapweske.com> Message-ID: The MS Farsite guys have done similar things. The published stats are probably skimpier than you'd like, but are a good place to start. On Tue, 12 Mar 2002, Justin Chapweske wrote: > Does anyone have any good pointers to research on optimal replication > strategies. By this I mean a quantification of how much a piece of > content should be replicated depending on its file size, available disk > space, and popularity of the content. From bert at akamail.com Tue Mar 12 12:34:02 2002 From: bert at akamail.com (bert@akamail.com) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? References: <3C8E4DF6.2010700@chapweske.com> Message-ID: <3C8E670B.30B386AD@akamail.com> See the following talk abstract: http://netseminar.stanford.edu/sessions/2002-01-31.html So yeah, square root in popularity is optimal. They find that Freenet's heuristic replication method closely approximates this. Don't know enough about mnet though to comment on that. Bert Justin Chapweske wrote: > > Does anyone have any good pointers to research on optimal replication > strategies. By this I mean a quantification of how much a piece of > content should be replicated depending on its file size, available disk > space, and popularity of the content. > > I once read something about the "square root of its popularity" > (whatever that means) as being the sweet spot for replication. > > I'm also curious how close systems like Freenet and Mnet come to this ideal. > > Thanks, > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers From hal at finney.org Tue Mar 12 13:42:02 2002 From: hal at finney.org (hal@finney.org) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? Message-ID: <200203122142.g2CLgsx31971@finney.org> Bert writes: > See the following talk abstract: > > http://netseminar.stanford.edu/sessions/2002-01-31.html > > So yeah, square root in popularity is optimal. They find that Freenet's > heuristic replication method closely approximates this. Don't know > enough about mnet though to comment on that. An earlier(?) version of the paper by this author is available from http://theory.Stanford.EDU/~cao/p2p-search.ps. Section 5 explains the square root law. Hal From justin at chapweske.com Tue Mar 12 15:23:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? References: <3C8E4DF6.2010700@chapweske.com> <3C8E670B.30B386AD@akamail.com> Message-ID: <3C8E8DBD.20200@chapweske.com> Perhaps the answer is simpler than I think it is. The square root statement is in regards to maximizing availability to minimze search traffic: "We also show that, in unstructured networks, an object's replication ratio should be proportional to the square root of its popularity in order to minimize overall network search traffic." The systems that I'm interested in track content locations explicitly, so finding the content isn't a problem. What I'm looking for is a good predictive prefetching policy for nodes in a distributed caching system. The basic property that I'm looking for is to replicate a piece of content just enough so that its mirrors have enough bandwidth to fully satisfy demand for that piece of content. I want to optimize bandwidth while minimizing storage....sort of a distributed LRU...but done pre-emptively rather than on demand. Any ideas/relevent research? Thanks, -Justin bert@akamail.com wrote: > See the following talk abstract: > > http://netseminar.stanford.edu/sessions/2002-01-31.html > > So yeah, square root in popularity is optimal. They find that Freenet's > heuristic replication method closely approximates this. Don't know > enough about mnet though to comment on that. > > Bert > > > Justin Chapweske wrote: > >>Does anyone have any good pointers to research on optimal replication >>strategies. By this I mean a quantification of how much a piece of >>content should be replicated depending on its file size, available disk >>space, and popularity of the content. >> >>I once read something about the "square root of its popularity" >>(whatever that means) as being the sweet spot for replication. >> >>I'm also curious how close systems like Freenet and Mnet come to this ideal. >> >>Thanks, >> >>-- >>Justin Chapweske, Onion Networks >>http://onionnetworks.com/ >> >>_______________________________________________ >>p2p-hackers mailing list >>p2p-hackers@zgp.org >>http://zgp.org/mailman/listinfo/p2p-hackers >> > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From justin at chapweske.com Tue Mar 12 15:26:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? References: <200203121930.g2CJUnr25833@finney.org> Message-ID: <3C8E8E56.7050001@chapweske.com> Thanks Hal, the Zipf information is very useful....that'll provide me with some good reading material for a while. > > I don't know of research on exactly this topic, but there is a general > observation on popularity of items called Zipf's law. See for example > http://linkage.rockefeller.edu/wli/zipf/. Quoting from there, "Zipf's > law, named after the Harvard linguistic professor George Kingsley Zipf > (1902-1950), is the observation that frequency of occurrence of some > event (P), as a function of the rank (i) when the rank is determined > by the above frequency of occurrence, is a power-law function P_i ~ > 1/i^a with the exponent a close to unity." > > There are many phenomena which follow Zipf's law, including web pages > and English words. Chances are the documents in a file sharing > system would follow it as well. > > Under this law, if the most popular item gets N hits, the 2nd most popular > item gets N/2 hits; the third most popular gets N/3 hits, and so on. > > Turning this into a replication strategy would probably depend on > your goals. Do you want to be strictly driven by popularity, so that > an item is replicated proportionally to how popular it is? Or do you > want to guarantee storage for even unpopular items, perhaps allowing > for some degradation in accessibility for the most popular items? > > Using the square root of popularity rank would seem to be a compromise > between a straight Zipf law replication (which would replicate > proportional to popularity ranking) and an even distribution where all > documents are replicated equally. > > Hal Finney > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From gojomo at usa.net Tue Mar 12 16:08:01 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [Re: [p2p-hackers] Optimal Replication?] Message-ID: <20020313000739.21525.qmail@uadvg137.cms.usa.net> Why preemptively? How will you estimate how "popular" something is before-hand? Are you suggesting that when a node notices it has "extra" bandwidth, it grabs something else to mirror, in an effort to "smooth out" the bandwidth usage across the whole net? These seem to be questions that are mainly interesting on the margins, as the system changes (nodes coming and going, popularities growing and receding). So I find it hard to imagine a preemptive system doing better than one that replicates content as it is requested -- unless you were in a domain where you had a really good idea of something's *future* popularity. - Gojomo Justin Chapweske wrote: > Perhaps the answer is simpler than I think it is. The square root > statement is in regards to maximizing availability to minimze search > traffic: > > "We also show that, in unstructured networks, an object's replication > ratio should be proportional to the square root of its popularity in > order to minimize overall network search traffic." > > The systems that I'm interested in track content locations explicitly, > so finding the content isn't a problem. What I'm looking for is a good > predictive prefetching policy for nodes in a distributed caching system. > > The basic property that I'm looking for is to replicate a piece of > content just enough so that its mirrors have enough bandwidth to fully > satisfy demand for that piece of content. I want to optimize bandwidth > while minimizing storage....sort of a distributed LRU...but done > pre-emptively rather than on demand. > > Any ideas/relevent research? > > Thanks, > > -Justin > > > bert@akamail.com wrote: > > See the following talk abstract: > > > > http://netseminar.stanford.edu/sessions/2002-01-31.html > > > > So yeah, square root in popularity is optimal. They find that Freenet's > > heuristic replication method closely approximates this. Don't know > > enough about mnet though to comment on that. > > > > Bert > > > > > > Justin Chapweske wrote: > > > >>Does anyone have any good pointers to research on optimal replication > >>strategies. By this I mean a quantification of how much a piece of > >>content should be replicated depending on its file size, available disk > >>space, and popularity of the content. > >> > >>I once read something about the "square root of its popularity" > >>(whatever that means) as being the sweet spot for replication. > >> > >>I'm also curious how close systems like Freenet and Mnet come to this ideal. > >> > >>Thanks, > >> > >>-- > >>Justin Chapweske, Onion Networks > >>http://onionnetworks.com/ > >> > >>_______________________________________________ > >>p2p-hackers mailing list > >>p2p-hackers@zgp.org > >>http://zgp.org/mailman/listinfo/p2p-hackers > >> > > _______________________________________________ > > p2p-hackers mailing list > > p2p-hackers@zgp.org > > http://zgp.org/mailman/listinfo/p2p-hackers > > > > > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers From justin at chapweske.com Tue Mar 12 17:15:02 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [Re: [p2p-hackers] Optimal Replication?] References: <20020313000739.21525.qmail@uadvg137.cms.usa.net> Message-ID: <3C8EA7DA.5040707@chapweske.com> I'm not trying to preempt future popularity, rather I'm trying to meet current demand w/o relying on the traditional write-through caching approach. Caching and LRU work because each request, no matter if it is a hit or miss, go through the caching node. In this system, requests are only made when it is going to be a hit, so I would be most interested in some way for nodes to communicate file popularity information with each other w/o resorting to requesting content on misses... So I guess my two goals are: o Communicate object popularity information w/o relying on blind requests and cache misses. o Figure out some heuristic based on the popularity information for choosing which objects to cache. This is obviously a very open ended problem that I expect a wide number of possible solutions to. Gordon Mohr wrote: > Why preemptively? How will you estimate how "popular" something > is before-hand? > > Are you suggesting that when a node notices it has "extra" > bandwidth, it grabs something else to mirror, in an effort > to "smooth out" the bandwidth usage across the whole net? > > These seem to be questions that are mainly interesting on > the margins, as the system changes (nodes coming and going, > popularities growing and receding). So I find it hard to > imagine a preemptive system doing better than one that > replicates content as it is requested -- unless you were > in a domain where you had a really good idea of something's > *future* popularity. > > - Gojomo > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From sam at neurogrid.com Tue Mar 12 17:33:01 2002 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Re: Optimal Replication? References: <20020313000739.21525.qmail@uadvg137.cms.usa.net> <3C8EA7DA.5040707@chapweske.com> Message-ID: <3C8EAC70.7010205@neurogrid.com> Hi Justin, You might check out some distributed database replication strategies http://citeseer.nj.nec.com/wiesmann00database.html I have s link to some stuff about Zipf Distribution that I find very helpful (I just read Gnutella queries follow the Zipf distribution) http://www.cut-the-knot.com/do_you_know/zipfLaw.html As regards pre-empting future popularity - I think it can be done. There are more complex schemes that LRU that look at an items popularity over a time scale. Using an appropriate discounting scheme one could take into account not just how long since something was requested, but interpolate the information about the time since each of its previous requests. I have a partial scheme developed for this in NeuroGrid to determine relative popularity of items to an individual user. However I have yet to identify any similar work on this .. well nothing that comes close enough to help me solve the existing problems with this approach. so I don't have a reference as such - other than my own thoughts on the subject. If anybody knows about any maths for interpreting time series in this manner I would be very interested, CHEERS> SAM Justin Chapweske wrote: > I'm not trying to preempt future popularity, rather I'm trying to meet > current demand w/o relying on the traditional write-through caching > approach. > > Caching and LRU work because each request, no matter if it is a hit or > miss, go through the caching node. In this system, requests are only > made when it is going to be a hit, so I would be most interested in > some way for nodes to communicate file popularity information with > each other w/o resorting to requesting content on misses... > > So I guess my two goals are: > > o Communicate object popularity information w/o relying on blind > requests and cache misses. > > o Figure out some heuristic based on the popularity information for > choosing which objects to cache. > > This is obviously a very open ended problem that I expect a wide > number of possible solutions to. From MBleyer at DEFiNiENS.com Wed Mar 13 03:48:01 2002 From: MBleyer at DEFiNiENS.com (Bleyer, Michael) Date: Sat Dec 9 22:11:44 2006 Subject: [Re: [p2p-hackers] Optimal Replication?] Message-ID: <023814FAC196D5119E4A00D0B76C0F98052056@mmuc.definiens.com> > o Figure out some heuristic based on the popularity information for > choosing which objects to cache. Assuming that both your disk space and bandwith of your caching node are limited and there are 2 objects A and B being requested, which together have a size larger than your cache disk size (but each by itself small enough to fit). Assuming further that object A is currently popular and cached, B is not cached, but B is becoming increasingly more popular while the popularity of A decreases. Now you want your heuristic to tell you at which point it will be more efficient to ditch object A in favour of caching object B? That should be simple, basically just multiply size * number of requests to optimize for bandwith. > o Communicate object popularity information w/o relying on blind > requests and cache misses. Now if node 1 currently stores object B and node 3 currently stores object A and the network looks like 1-2-3 and node 3 being the above-mentioned node, then all you need is the requests themselves. Node 3 would cache A and answer those requests itself. Requests for B would go to node 2, who would either pass them on or decide to cache itself. Node 2 can figure out the popularity of B simply from the requests themselves because it gets them all. As soon as node 3 decides to cache B itself, there'd be no more requests. So why would you need separate Meta-messages to communicate object popularity? The only reason you'd need to seperately communicate popularity would be if you predicted future popularity and a node requests (or is being sent) an object before the demand onslaught actually hits it. Please tell me if I'm missing something? I'm interested in this issue because I'm thinking about predicting traffic patterns in different areas based on the time of day (e.g. something like: Europe awake, US still sleeping, but more bandwith available at night). Although I'm not sure it really performs better if a self-regulating simple approach (caching/LRU) does it fine. Depends on the quality of the prediction I guess. Mike From jbone at jump.net Thu Mar 14 13:22:01 2002 From: jbone at jump.net (Jeff Bone) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Optimal Replication? References: Message-ID: <3C911385.F1ED6BA@jump.net> Lucas Gonze wrote: > The MS Farsite guys have done similar things. The published stats are > probably skimpier than you'd like, but are a good place to start. If you send them e-mail they'll provide you with some of their datasets. (They sent them to me, anyway, a little over a year ago.) jb From bram at gawth.com Thu Mar 14 15:04:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] next p2p-hackers meeting - the 24th Message-ID: Since people seem agreeable to having another hackers meeting on sunday, I suggest we have it a week from this sunday, on the 24th, starting at 2:00 pm, at the metreon, in san francisco. Meeting in the same place - food court area, lower level, the region you have to walk up some stairs to get into - hopefully I'll have purple hair by then, which should make us all easy to spot. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sun Mar 17 13:55:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] good article on REST Message-ID: REST is actually an anti-buzzword. It basically says 'Use http the way it was designed.' http://www.xml.com/pub/a/2002/02/20/rest.html?page=1 The strength and flexibility of REST comes from the pervasive use of URIs. This point cannot be over-emphasized. When the Web was invented it had three components: HTML, which was about the worst markup language of its day (other than being simple); HTTP, which was the most primitive protocol of its day (other than being simple), and URIs (then called URLs), which were the only generalized, universal naming and addressing mechanism in use on the Internet. Why did the Web succeed? Not because of HTML and not because of HTTP. Those standards were merely shells for URIs. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From tboyle at rosehill.net Sun Mar 17 14:29:02 2002 From: tboyle at rosehill.net (Todd Boyle) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] good article on REST In-Reply-To: Message-ID: <5.1.0.14.0.20020317142920.038c60c0@popmail.cortland.com> At 01:54 PM 3/17/02, Bram Cohen wrote: >REST is actually an anti-buzzword. It basically says 'Use http the way it >was designed.' > >http://www.xml.com/pub/a/2002/02/20/rest.html?page=1 > > > >The strength and flexibility of REST comes from the pervasive use of >URIs. This point cannot be over-emphasized. When the Web was invented it >had three components: HTML, which was about the worst markup language of >its day (other than being simple); HTTP, which was the most primitive >protocol of its day (other than being simple), and URIs (then called >URLs), which were the only generalized, universal naming and addressing >mechanism in use on the Internet. Why did the Web succeed? Not because of >HTML and not because of HTTP. Those standards were merely shells for URIs. I busted my ass getting the UN/CEFACT to include URI support in the Core Component Technical Specification. This is the specification for the standardization of vocabulary in e-business. Please read it and understand how significant it is, that you will be able to send a snatch of information to any of 6 billion other people, it will have an unambiguous meaning. http://www.unece.org/cefact/ebxml/ebXML_CCTS_Part1_V1-8.pdf That means, you can use any platform, language, script, device etc. because the content is syntax neutral and it's being agreed among the largest global corproations after 30 years of anguish (EDI) because they cannot get interoperability between themselves without a standard P2P language of ebusiness. Anguish because, that also allows YOU to do business, Thanks TOdd http://www.gldialtone.com http://www.arapxml.net "AR/AP everywhere." > > >-Bram Cohen > >"Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers From bram at gawth.com Mon Mar 18 11:01:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] new release out Message-ID: I just pushed out version 2.6.2 of BitTorrent, you can get it from the download page - http://bitconjurer.org/BitTorrent/download.html New in this release - a nicer (or 'real') GUI, continuing to upload after done downloading, and a ton of small performance and stability enhancements. Next release will be backwards-incompatible - that will be the one with multi-file and re-requesting, after which we should be ready for downloads with hundreds of simultaneous downloaders. That should be the last backwards-incompatible release, and if nothing new really bad turns up, the next release after it will be the first one with no version check. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From greg at electricrain.com Fri Mar 22 11:48:01 2002 From: greg at electricrain.com (Gregory P. Smith) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? Message-ID: <20020322194732.GA3428@zot.electricrain.com> http://www.shacknews.com/extras/e_steam/ anyone know anything about it? That article is a very vague description but it sounds very similar content distribution things that half of us have worked on in the last couple years. (though it sounds more akamai-ish than full p2p-ish as it doesn't mention the end users computers participating) -- Gregory P. Smith From justin at chapweske.com Fri Mar 22 12:11:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? References: <20020322194732.GA3428@zot.electricrain.com> Message-ID: <3C9B8F97.2030500@chapweske.com> Yeah, the most I could glean from it is that they are trying to establish relationships with ISPs who will then probably take all of the bandwidth burdon....I doubt that there is anything technically interesting about their system. Gregory P. Smith wrote: > http://www.shacknews.com/extras/e_steam/ > > anyone know anything about it? That article is a very vague description > but it sounds very similar content distribution things that half > of us have worked on in the last couple years. (though it sounds > more akamai-ish than full p2p-ish as it doesn't mention the end users > computers participating) > > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From bram at gawth.com Fri Mar 22 17:19:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? In-Reply-To: <3C9B8F97.2030500@chapweske.com> Message-ID: Justin Chapweske wrote: > Yeah, the most I could glean from it is that they are trying to > establish relationships with ISPs who will then probably take all of the > bandwidth burdon....I doubt that there is anything technically > interesting about their system. Yeah, that's my impression as well. All content distribution tools seem to fall into one of three general categories - a) Akamai b) BitTorrent c) Napster If it's all server-side http it's like akamai, if it requires a client install but then web-integrates it's like BitTorrent, and if it integrates keyword-based search it's like Napster. Any new content distribution systems should as a first step figure out which one they're a clone of, or even better, figure out something different to do - there are already very strong competitors in each of the above categories. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From zooko at zooko.com Sat Mar 23 05:14:01 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list Message-ID: There are currently 186 total subscribers to the p2p-hackers mailing list. There has been a steady increase in subscribers over the last couple of weeks. Why is it so quiet? I don't know. Perhaps everyone is busy coding. Also, a lot of people talk on IRC channels on irc.openprojects.net, and once they've made their points in IRC chat, they are less likely to type the idea in again and flesh it out to post to a list. At least, that's true for me. I've recently started making a conscious effort to post to mnet-devel@lists.sourceforge.net [1] whenever I say something that would be of interest to that list. I've discovered that having the word "hacker" in the name of the mailing list attracts and endless stream of people who have the wrong idea. I've started challenging subscribers to say something that proves that they know what they list is about. One fellow, when I did that, replied with a stolen password to access the Microsoft Developer Network download site. I've also recently filtered out two posts from one particular person. I deemed that they would be uninteresting to the subscribers. One of them was a one-liner that said we should consider our virtual network to have a different topology from our physical network. Note that for 183 of the current subscribers, your posts go through automatically and I do not have the opportunity to filter them before everyone sees them. This fellow just happened to be one of the three who I had marked for review. Okay that's all about the state of the p2p-hackers mailing list. I'm impressed with the quality (not to mention quantity) of subscribers that are currently registered, and I'm hoping that something will spark a really productive and creative exchange. Regards, Zooko [1] http://sourceforge.net/mailarchive/forum.php?forum_id=7702 --- zooko.com Security and Distributed Systems Engineering --- From jeff at platypus.ro Sat Mar 23 06:31:01 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list References: Message-ID: <003c01c1d277$4f22b3a0$2002a8c0@jdarcyvaio> > I've also recently filtered out two posts from one particular person. I deemed > that they would be uninteresting to the subscribers. One of them was a > one-liner that said we should consider our virtual network to have a different > topology from our physical network. Why would you consider that uninteresting to subscribers? As described, it sounds like a statement of a common meme among people working on overlay networks, which AFAIK are of very immediate interest to people here. It's a meme I happen to reject personally, but I think it's very much worth discussing. From jeff at platypus.ro Sat Mar 23 06:45:01 2002 From: jeff at platypus.ro (Jeff Darcy) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? References: Message-ID: <004401c1d279$2ed0dbc0$2002a8c0@jdarcyvaio> > All content distribution tools seem to > fall into one of three general categories - > > a) Akamai > > b) BitTorrent > > c) Napster I think that's way too simplistic, Bram. Where, for example, would Freenet fit into that, or MNet? Neither could be considered a clone of BitTorrent, which they preceded. I see a whole bunch of different differentiators here: * Centralized vs. hierarchical vs. P2P * Transient vs. permanent (a.k.a. communication vs. storage, with some systems in between) * Focus on security/anonymity vs. focus on performance * Replication+redirection vs. multi-level caching * Push vs. pull * Consistent vs. inconsistent * Block vs. file granularity. Wes Felter presented a different taxonomy at the first O'Reilly P2P conference (http://felter.org/wesley/p2p/one/P2PInfrastructure.html) but even within its more restricted domain it also allows for many fully legitimate permutations that can in no reasonable way be considered clones of the three systems you mention. I agree with you that it's very important to decide and remember what type of system you're trying to build, according to these sorts of criteria, but IMO treating it as a choice between members of a single (small) enumerated set is too limiting. From zooko at zooko.com Sat Mar 23 06:56:01 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list In-Reply-To: Message from "Jeff Darcy" of "Sat, 23 Mar 2002 09:30:40 EST." <003c01c1d277$4f22b3a0$2002a8c0@jdarcyvaio> References: <003c01c1d277$4f22b3a0$2002a8c0@jdarcyvaio> Message-ID: Jeff Darcy wrote: > > > I've also recently filtered out two posts from one particular person. I > deemed > > that they would be uninteresting to the subscribers. One of them was a > > one-liner that said we should consider our virtual network to have a > different > > topology from our physical network. > > Why would you consider that uninteresting to subscribers? As described, it > sounds like a statement of a common meme among people working on overlay > networks, which AFAIK are of very immediate interest to people here. It's a > meme I happen to reject personally, but I think it's very much worth > discussing. That's a good question. The best answer would be to show you the original rejected post, but I don't have a copy. I think that the original post as written was even less substantive than my paraphrase of it above. In the future, I'll be careful to archive rejected posts. I'll also err a little more on the side of inclusivity. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- From pete at petertodd.ca Sat Mar 23 08:53:01 2002 From: pete at petertodd.ca (Peter Todd) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list In-Reply-To: References: Message-ID: <20020323165258.GC490@petes.localdomain> On Sat, Mar 23, 2002 at 05:11:18AM -0800, Zooko wrote: > There are currently 186 total subscribers to the p2p-hackers mailing list. > > There has been a steady increase in subscribers over the last couple of weeks. > > Why is it so quiet? I don't know. Perhaps everyone is busy coding. Also some of us, such as I, are only here to learn more about p2p. I have little intention of actually contributing for the time being. Lack of time, being one of the reasons. :) -- Need some Linux help or custom C(++) programming? Drop me a line and I'll see what I can do. Resume at http://www.petertodd.ca/resume.php pete@petertodd.ca http://www.petertodd.ca -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 232 bytes Desc: not available Url : http://zgp.org/pipermail/p2p-hackers/attachments/20020323/363bac42/attachment.pgp From tboyle at rosehill.net Sat Mar 23 11:57:01 2002 From: tboyle at rosehill.net (Todd Boyle) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list In-Reply-To: Message-ID: <5.1.0.14.0.20020323115328.038b8b40@popmail.cortland.com> Thanks for your post. It is essential, good stewardship. Too many lists are just a chaotic dumping ground without any grooming at all... At 05:11 AM 3/23/02, Zooko wrote: >There are currently 186 total subscribers to the p2p-hackers mailing list. >There has been a steady increase in subscribers over the last couple of weeks. Could be because there has been a reduction in attrition? The natural state of a list is to gradually grow, then occasionally have a big drop when conversation takes a turn in one direction or another. >Why is it so quiet? I don't know. Perhaps everyone is busy coding. There is always the megatrend that over the past 3 years a $Trillion was plowed into technology investments and the reduction is so great its like, musical chairs for 30 kids, and you jerk out 25 of the chairs. So, there will just be a lot of milling around for a while, until a whole *bunch* of people go out to the physical economy. Probably I will be among these since I don't have a deep software background. >Also, a lot of people talk on IRC channels on irc.openprojects.net, and once >they've made their points in IRC chat, they are less likely to type the >idea in >again and flesh it out to post to a list. At least, that's true for >me. I've >recently started making a conscious effort to post to >mnet-devel@lists.sourceforge.net [1] whenever I say something that would be >of interest to that list. IRC chat (or yahoo chat which has voice and other nice things) is the foundation for many of the top projects. The downside is that the content is lost forever, from mailing lists to IRC chat. So be it. The GNUE project has a Kernel Cousins volunteer--that woudl be so great if P2P hackers had one too. http://www.gnue.org/ >I've discovered that having the word "hacker" in the name of the mailing list >attracts and endless stream of people who have the wrong idea. Why not drop the word hacker? Semantic alignment matters, TOdd Todd Boyle CPA 9745-128th Ave NE Kirkland WA International Accounting Services, LLC www.gldialtone.com tboyle@rosehill.net 425-827-3107 project www.arapxml.net ... AR/AP everywhere. From bram at gawth.com Sat Mar 23 14:30:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Don't forget - meeting tomorrow Message-ID: Remember, we're having a meeting tomorrow at the Metreon in San Francisco, in the food court area. I unfortunately do not yet have purple hair, so we can't be spotted that way. You can look for the guy with long hair with blond streaks who was on stage a bunch at CodeCon though. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sat Mar 23 14:33:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Don't forget - meeting tomorrow In-Reply-To: Message-ID: Bram Cohen wrote: > Remember, we're having a meeting tomorrow at the Metreon in San Francisco, > in the food court area. I forgot to mention the time - it will be at 2pm. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From badapple at netnitco.net Sat Mar 23 14:56:01 2002 From: badapple at netnitco.net (Fred Grott) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list References: <5.1.0.14.0.20020323115328.038b8b40@popmail.cortland.com> Message-ID: <003701c1d2bd$d7147aa0$ad92b0d8@fred> Actually Todd..hacker is so bad.. we should not change the word hacker.. Just because the press in describing the criminal has misused the term hacker..we should not stoop to their asine level and get rid of the term.. I have been quit until know because I am in long job hunt which will end shortly and then I can code again.. So expect me to get more vocal on the list real soon ----- Original Message ----- From: "Todd Boyle" To: Sent: Saturday, March 23, 2002 2:03 PM Subject: Re: [p2p-hackers] state of the p2p-hackers mailing list > Thanks for your post. It is essential, good stewardship. Too many > lists are just a chaotic dumping ground without any grooming at all... > > At 05:11 AM 3/23/02, Zooko wrote: > > >There are currently 186 total subscribers to the p2p-hackers mailing list. > >There has been a steady increase in subscribers over the last couple of weeks. > > Could be because there has been a reduction in attrition? The natural state > of a list is to gradually grow, then occasionally have a big drop when > conversation takes a turn in one direction or another. > > >Why is it so quiet? I don't know. Perhaps everyone is busy coding. > > There is always the megatrend that over the past 3 years a $Trillion was > plowed into technology investments and the reduction is so great its like, > musical chairs for 30 kids, and you jerk out 25 of the chairs. So, there > will just be a lot of milling around for a while, until a whole *bunch* of > people go out to the physical economy. Probably I will be among these > since I don't have a deep software background. > > >Also, a lot of people talk on IRC channels on irc.openprojects.net, and once > >they've made their points in IRC chat, they are less likely to type the > >idea in > >again and flesh it out to post to a list. At least, that's true for > >me. I've > >recently started making a conscious effort to post to > >mnet-devel@lists.sourceforge.net [1] whenever I say something that would be > >of interest to that list. > > IRC chat (or yahoo chat which has voice and other nice things) is the > foundation for many of the top projects. The downside is that the > content is lost forever, from mailing lists to IRC chat. So be it. > The GNUE project has a Kernel Cousins volunteer--that woudl be so > great if P2P hackers had one too. > http://www.gnue.org/ > > > >I've discovered that having the word "hacker" in the name of the mailing list > >attracts and endless stream of people who have the wrong idea. > > Why not drop the word hacker? Semantic alignment matters, > > TOdd > Todd Boyle CPA 9745-128th Ave NE Kirkland WA > International Accounting Services, LLC www.gldialtone.com > tboyle@rosehill.net 425-827-3107 project www.arapxml.net > ... AR/AP everywhere. > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From burton at openprivacy.org Sat Mar 23 15:10:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Resources discussing secure time (nonce) in a distributed environment. Message-ID: <87hen6x6i7.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Does anyone have any references they would recommend which talk about the problems of time in a secure and distributed environment? Specifically, how do you keep others from cheating and saying that an event happened in the past when it actually happened in the present? I have tried to get some resources from google and other crypto hackers but I can't seem to find anything substantial. There HAS to be some prior research in this area! Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ ... in fact what I would like to see is thousands of com- puter scientists let loose to do whatever they want. That's what really advances the field. - Donald Knuth -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8nQHPAwM6xb2dfE0RApgNAKDROfBIm50Fab9tHoNsgSDv9t9gCwCeOO2U vFEeOuXNCAsUOedFytt26to= =u1+q -----END PGP SIGNATURE----- From fen at openprivacy.org Sat Mar 23 15:51:02 2002 From: fen at openprivacy.org (Fen Labalme) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Resources discussing secure time (nonce) in a distributed environment. In-Reply-To: <87hen6x6i7.fsf@openprivacy.org> References: <87hen6x6i7.fsf@openprivacy.org> Message-ID: <15517.5326.823888.665525@openprivacy.org> See the FAQ on Digital Tinme Stamping at http://saturn.tcs.hut.fi/~helger/crypto/link/timestamping/ In particular, I have been following Stuar Haber's work in this area, see: http://www.star-lab.com/stuart/dig-time-stamping.html Stuart's now at InterTrust and is interested in distributed, secure and anonymous P2P technologies (which we talk about a bit). He's a good guy, despite being connected to an DRM company... Fen == Kevin A. Burton writes: > Does anyone have any references they would recommend which talk about the > problems of time in a secure and distributed environment? > > Specifically, how do you keep others from cheating and saying that an event > happened in the past when it actually happened in the present? > > I have tried to get some resources from google and other crypto hackers but I > can't seem to find anything substantial. > > There HAS to be some prior research in this area! > > Kevin From gojomo at usa.net Sat Mar 23 16:06:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available Message-ID: <008201c1d2c7$8a88cab0$650a000a@gojovaio> You can now fetch Bitzi's XML summary info about arbitrary files -- aka our "Tickets" -- via a simple HTTP GET. Full details are available at: http://bitzi.com/developer/xml [excerpted below] Other relevant recent updates at Bitzi include: - New homepage and page layout which should better highlight how Bitzi can help users, developers, creators, and advertisers http://bitzi.com/ - More developer info at: http://bitzi.com/developer - More information about the OpenBits dataset, and some minor license wording tweaks, at: http://bitzi.com/openbits Comments and questions wanted. What sorts of services or tools would help you use Bitzi metadata in your file-sharing or content-delivery applications? ================== FROM http://bitzi.com/developer/xml ================== Bitzi XML Ticket Service RDF-compliant XML describing files in the Bitzi catalog is available from the URLs: http://ticket.bitzi.com/rdf/?bitprint? http://ticket.bitzi.com/rdf/?SHA1? Where ?bitprint? represents a full Bitzi bitprint (Base32 SHA1 value + '.' + Base32 TigerTree value) and ?SHA1? represents just a Base32 SHA1 value. These values may, but need not be, preceded by URN labelling like "urn:bitprint:" or "urn:sha1:". For example: http://ticket.bitzi.com/rdf/BCLD3DINKJJRGYGHIYAX7HG5HXSM3XNH.E4IHTEMZIJE4NBCWSBZ6TIWQTDGYYXVPGIRJ5KQ http://ticket.bitzi.com/rdf/urn:sha1:BCLD3DINKJJRGYGHIYAX7HG5HXSM3XNH The returned XML will be a complete, raw Bitzi Ticket - all the best available summary information for the given file identifier. Further documentation of the internal Ticket format is coming soon; browsing a few will reveal them to be helpfully self-descriptive. We have sought to conform with the Common-XML 1.0 conventions for straightforward XML, and have reused pre-existing namespaces from the W3C, Dublin Core Initiative, and MusicBrainz where appropriate. The root element of each Ticket currently looks like: If the Bitzi OpenBits Catalog does not have any information about the requested file, you will receive an empty but well-formed Ticket, containing only bookkepping fields about the Ticket's minting time, expiration time, and recommended filename as a standalone file. As the traffic against the ticket.bitzi.com URLs increases, they may respond with unique busy, redirect, and challenge codes designed to shunt lookups to other avenues. Documentation of these special cases, and suggestions for dealing with them, is coming soon - but in the meantime, be ready to handle failed retrievals gracefully. ================ END FROM http://bitzi.com/developer/xml ================ - Gojomo ____________________ Gordon Mohr, gojomo@ bitzi.com, Bitzi CTO From burton at openprivacy.org Sat Mar 23 17:17:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Resources discussing secure time (nonce) in a distributed environment. In-Reply-To: <15517.5326.823888.665525@openprivacy.org> References: <87hen6x6i7.fsf@openprivacy.org> <15517.5326.823888.665525@openprivacy.org> Message-ID: <87y9givk93.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Fen Labalme writes: > See the FAQ on Digital Tinme Stamping at > http://saturn.tcs.hut.fi/~helger/crypto/link/timestamping/ It seems like there are two camps in the crypto world. Those who propose distributed solutions (web of trust, SDSI) and those who suggest (centralized) infrastructures. DTS is based on long running time servers that can provide signed time stamps. I don't think this fits very well into the P2P space. It would be different if we had a distributed supernodes (hundreds) that could provide DTS timestamps. Maybe so that they only have to be around for a few years. Other nodes in your web of trust could certify that timestamps created by this DTS are valid for a certain range of time. The problem is you would need to compute a reliable timestamp based on multiple time servers. I would want to do this by using the reputation of each supernode/time server. The only problem is that I think you need a time service to compute reputation (in the long term). Anyway... maybe we just need to bring up many time servers that are reliable and not use web of trust style computation of their reputation. I guess my original interest was if there was any mathematical research done in computing secure time stamps. I would rather trust math than a 3rd party. :) > In particular, I have been following Stuar Haber's work in this area, see: > http://www.star-lab.com/stuart/dig-time-stamping.html > > Stuart's now at InterTrust and is interested in distributed, secure and > anonymous P2P technologies (which we talk about a bit). He's a good guy, > despite being connected to an DRM company... Thanks.. Keviny - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ Software is only an operating system if it can be trusted. Windows does not qualify as an Operating System. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8nSi4AwM6xb2dfE0RAsUNAKC8z/aXOvy1/G08XPig1WGyyEpLtwCeKlEo b4XGsckp9fzCGX9uS1KGgkc= =MZy2 -----END PGP SIGNATURE----- From blanu at bozonics.com Sat Mar 23 17:26:01 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Resources discussing secure time (nonce) in a distributed environment. In-Reply-To: <87hen6x6i7.fsf@openprivacy.org> Message-ID: > Does anyone have any references they would recommend which talk about the > problems of time in a secure and distributed environment? > > Specifically, how do you keep others from cheating and saying that an event > happened in the past when it actually happened in the present? Someone at the first conference on anonymity and unobservability (now call privacy-enhancing technologes) gave a speech on just this topic. However, my copy of the preoceedings seems to totally lack that topic. But if you can track down the speaker from that conference, I'd bet that he could refer you to the body of prior work. Of course I don't remember his name, but Hannes Federath, the conference organized, should probably be able to direct you to him. From ethan.eade at duke.edu Sat Mar 23 17:46:01 2002 From: ethan.eade at duke.edu (Ethan Eade) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: <000201c1d2d5$c29e3620$2cdf1098@ethan> One might wish to have the equivalent of "accounts" in a p2p network, that restrict the identity one is allowed to use. For instance, in a p2p decentralized version of instant messaging, where any node enters and leaves the network on the order of minutes (or seconds,) how can the network maintain persistency about "accounts" -- if I connect and register as "Ethan" and then sign off, what's to keep my archnemesis from registering as "Ethan" when he signs on? The nodes holding information about my initial registration might all be gone by the time my enemy signs on, so how can the network authenticate a user in this situation? I can see how one node can authenticate another based on certificates, but how can the network authenticate the advertisement of an identity? A false advertiser, even if it can't pull off communication with other nodes -- can keep any other nodes from reaching the real owner of the identity, especially if overlay routing is done using a distributed index. I think this is applicable to many p2p systems, as most don't really allow node identification now -- they are more content oriented -- but node identification could be very useful, both for messaging/presence and for being able to "browse" the content of a specfic node (much like one can, for example, on Napster.) Although this question applies generally, I'm thinking specifically about distributed index based networks such as Chord or Pastry. Any thoughts or pointers? ~Ethan Eade -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20020323/996b524c/attachment.html From burton at openprivacy.org Sat Mar 23 17:52:02 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Don't forget - meeting tomorrow In-Reply-To: References: Message-ID: <87pu1uvilj.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Bram Cohen writes: > I unfortunately do not yet have purple hair, so we can't be spotted that > way. You can look for the guy with long hair with blond streaks who was on > stage a bunch at CodeCon though. Or you can look for the really handsome guy! That will be me... :) Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ Iron rusts from disuse, stagnant water loses its purity, and in cold weather becomes frozen: even so does inaction sap the vigors of the mind. -- Leonardo da Vinci -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8nTEYAwM6xb2dfE0RAnLUAKCeYDqVzLZOv1umAsNxzFJ8hQM3SwCfU7HR /lLYRwuYJvMVCI+yce53fqk= =EkOf -----END PGP SIGNATURE----- From wesley at felter.org Sat Mar 23 18:07:02 2002 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network In-Reply-To: <000201c1d2d5$c29e3620$2cdf1098@ethan> Message-ID: on 3/23/02 7:46 PM, Ethan Eade at ethan.eade@duke.edu wrote: > One might wish to have the equivalent of "accounts" in a p2p > network, that restrict the identity one is allowed to use. For > instance, in a p2p decentralized version of instant messaging, where any > node enters and leaves the network on the order of minutes (or seconds,) > how can the network maintain persistency about "accounts" -- if I > connect and register as "Ethan" and then sign off, what's to keep my > archnemesis from registering as "Ethan" when he signs on? The nodes > holding information about my initial registration might all be gone by > the time my enemy signs on, so how can the network authenticate a user > in this situation? You should look at pet names and how they are implemented in Groove. http://www.erights.org/elib/capability/pnml.html http://zooko.com/distnames.html http://www.groove.net/pdf/brief-security.pdf Wes Felter - wesley@felter.org - http://felter.org/wesley/ From bram at gawth.com Sat Mar 23 18:20:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? In-Reply-To: <004401c1d279$2ed0dbc0$2002a8c0@jdarcyvaio> Message-ID: Jeff Darcy wrote: > > All content distribution tools seem to > > fall into one of three general categories - > > > > a) Akamai > > > > b) BitTorrent > > > > c) Napster > > I think that's way too simplistic, Bram. Where, for example, would Freenet > fit into that, or MNet? Freenet isn't a content distribution system, it's an anonymity system. MNet falls squarely into the Napster group. > * Centralized vs. hierarchical vs. P2P I'm doing the grouping based on how their UI works, so architecture is, for this categorization anyway, irrelevant. There are obviously other things one can say about how a system works. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From adam at cypherspace.org Sat Mar 23 18:24:01 2002 From: adam at cypherspace.org (Adam Back) Date: Sat Dec 9 22:11:44 2006 Subject: pub keys as ids, and auditable namespaces (Re: [p2p-hackers] Node identity in a dynamic peer network) In-Reply-To: <000201c1d2d5$c29e3620$2cdf1098@ethan>; from ethan.eade@duke.edu on Sat, Mar 23, 2002 at 08:46:47PM -0500 References: <000201c1d2d5$c29e3620$2cdf1098@ethan> Message-ID: <20020324022508.A1463726@exeter.ac.uk> Ah that ones easy if you don't mind what your identities look like. Every participant chooses a public and private signature key pair (eg DSA, RSA), and their "identity" is the public key (or the hash of the public key if you have some lookup mechanism, or the public key is anyway sent in the login message). The login process must include a proof of freshness (signature on random challenge from node connected to). By definition no one can find the same private key or the signature scheme is broken. If you want first-come first-served names, check out: http://www.cypherspace.org/p2p/auditable-namespace.html I haven't implemented the scheme but it may be interesting to give it a go for this kind of use. It's not fully distributed as such as it retains a distinction between name server nodes (like caching DNS servers) and clients (like DNS clients); but clients can audit name servers, and the protocol allows clients to undo local censorship on the part of some nodes from mutually distrusting other nodes. The scheme should allow reconstruction of the uncensored / unfiltered namespace so long as the full transaction set relating to that name can be recovered from the nameservers. Note you can also prevent a-priori censorship of names (useful for DNS systems that sometimes try to a-priori censor things like fuck.com) by delayed publishing where you first publish a commitment to a name before revealing the name. Unless there is a single hierarchical root, you'd also have to use the delay until full propagation before revealing the full name to avoid reactionary simultaneous competing claims to the same name. It's harder to avoid accidental simultaneously submitted name collisions -- this is what single roots are good for, and single roots may not be so bad if they are auditable, and are prevented from censoring by two stage announcements with commitments. Adam On Sat, Mar 23, 2002 at 08:46:47PM -0500, Ethan Eade wrote: > I can see how one node can authenticate another based on > certificates, but how can the network authenticate the advertisement of > an identity? A false advertiser, even if it can't pull off communication > with other nodes -- can keep any other nodes from reaching the real > owner of the identity, especially if overlay routing is done using a > distributed index. > I think this is applicable to many p2p systems, as most don't really > allow node identification now -- they are more content oriented -- but > node identification could be very useful, both for messaging/presence > and for being able to "browse" the content of a specfic node (much like > one can, for example, on Napster.) Although this question applies > generally, I'm thinking specifically about distributed index based > networks such as Chord or Pastry. Any thoughts or pointers? > ~Ethan Eade From wesley at felter.org Sat Mar 23 20:08:01 2002 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available In-Reply-To: <008201c1d2c7$8a88cab0$650a000a@gojovaio> Message-ID: on 3/23/02 6:04 PM, Gordon Mohr at gojomo@usa.net wrote: > You can now fetch Bitzi's XML summary info about arbitrary files -- > aka our "Tickets" -- via a simple HTTP GET. Full details are > available at: > > http://bitzi.com/developer/xml [excerpted below] This looks good. Are you planning a similar interface for submitting metadata? Have you considered using XML-Signature (or something similar) for your authentication needs? Wes Felter - wesley@felter.org - http://felter.org/wesley/ From gojomo at usa.net Sat Mar 23 23:14:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available References: Message-ID: <016d01c1d303$46a29fb0$650a000a@gojovaio> Wes Felter writes: > > http://bitzi.com/developer/xml [excerpted below] > > This looks good. Thanks! > Are you planning a similar interface for submitting metadata? Yes. In a way, we already have one -- you can do submits by simulating form-POSTs, in the style of our Bitcollider tool. However, for many kinds of submissions, you then have to confirm the content manually. We're considering XML-RPC gto enable a wider set of programmatic options for submitting metadata and rating metadata and files. But we'll also continue to support the plain form-POST method, perhaps with extra switches to "confirm-immediately" or "submit-anonymously". > Have you considered using XML-Signature (or something similar) for your > authentication needs? Yes, definitely. But we wanted to roll out this initial version of the service, to get real-world usage and feedback, even before being ready with cryptographic authentication. Hence, the weak, "boilerplate/trademark" style of authentication that you'll see if you view a raw Ticket. - Gojomo ____________________ Gordon Mohr, gojomo@ bitzi.com, Bitzi CTO From nobody at remailer.privacy.at Sun Mar 24 03:17:01 2002 From: nobody at remailer.privacy.at (Anonymous) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: <63329eca2d0c5eb1c37c844b424ab6bb@remailer.privacy.at> Ethan Eade writes: > One might wish to have the equivalent of "accounts" in a p2p > network, that restrict the identity one is allowed to use. For > instance, in a p2p decentralized version of instant messaging, where any > node enters and leaves the network on the order of minutes (or seconds,) > how can the network maintain persistency about "accounts" -- if I > connect and register as "Ethan" and then sign off, what's to keep my > archnemesis from registering as "Ethan" when he signs on? The nodes > holding information about my initial registration might all be gone by > the time my enemy signs on, so how can the network authenticate a user > in this situation? The general issue of secure, distributed naming is almost impossible to solve. Probably you would do better to abandon human-readable names and just let the "names" be public keys. Each name owner would hold the corresponding private key and prove ownership whenever necessary (by signing data with the private key). This provides fully unforgeable names which would be well suited as node identifiers. Trying to make them be human readable is an awful can of worms. From nobody at remailer.privacy.at Sun Mar 24 03:17:03 2002 From: nobody at remailer.privacy.at (Anonymous) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: A repost from coderpunks, June 2001: Maybe it would help if we had a canonical method for turning a key (or any string) into a name. Then this would *be* your name (pseudonym) when you used that key. No need for certificates or WoT. I found a downloadable database with 5163 first names and 88799 last names, from the U.S. census (interestingly enough almost 80% of the first names are female). By creating a first, middle and hyphenated last name you can get names like Thalia Kiesha Ficher-Dellos or Angelo Damion Rosenberry-Nico. While these don't exactly role trippingly off the tongue, they are not too unusual in today's multicultural world. These names represent 57 bits of entropy, which would make it quite expensive to generate a key which would match someone else's pseudonym. Unfortunately, even compressed, the census files require 306K bytes. This would be quite a bit of baggage to carry around with any program which wanted to display the pseudonyms associated with keys. Another possibility would be to use a fake-name generator. They have these for such things as fantasy role-playing games, and the databases are tiny, just a few hundred syllables and name-parts which get glued together. However the names are not particularly realistic, not even as natural as the slightly oddball names above, an example being Chalkall Jemcobs Kawilkan-Sediilip. It would seem more difficult to come up with a name that you might be comfortable having as your "virtual identity." P.S. In the future, people should use this method for choosing names for children. At birth each child would have a key generated in a secure token, and the public key would seed a PRNG to generate the new child's name. Then there will be no need for centralized certification agencies and each person's name will match his key. You know, if people would just let cryptographers run the world, it would be a much better place. From cloudcn at hotmail.com Sun Mar 24 03:17:04 2002 From: cloudcn at hotmail.com (cloud cloud) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list Message-ID: I do want to have more access to the forum,while the sensorship is too rigid to accept any naive(maybe not so naive)ideas.I agree sensorship to some extent less those unrelated articles be posted here.But to those related articles,even not so sophisticated,I do think the manager should give them some room.Who knows if it is a good idea in another way to think or express? >From: Zooko >Reply-To: p2p-hackers@zgp.org >To: p2p-hackers@zgp.org >Subject: [p2p-hackers] state of the p2p-hackers mailing list >Date: Sat, 23 Mar 2002 05:11:18 -0800 > >There are currently 186 total subscribers to the p2p-hackers mailing list. > >There has been a steady increase in subscribers over the last couple of weeks. > >Why is it so quiet? I don't know. Perhaps everyone is busy coding. > >Also, a lot of people talk on IRC channels on irc.openprojects.net, and once >they've made their points in IRC chat, they are less likely to type the idea in >again and flesh it out to post to a list. At least, that's true for me. I've >recently started making a conscious effort to post to >mnet-devel@lists.sourceforge.net [1] whenever I say something that would be >of interest to that list. > >I've discovered that having the word "hacker" in the name of the mailing list >attracts and endless stream of people who have the wrong idea. I've started >challenging subscribers to say something that proves that they know what they >list is about. One fellow, when I did that, replied with a stolen password to >access the Microsoft Developer Network download site. > >I've also recently filtered out two posts from one particular person. I deemed >that they would be uninteresting to the subscribers. One of them was a >one-liner that said we should consider our virtual network to have a different >topology from our physical network. Note that for 183 of the current >subscribers, your posts go through automatically and I do not have the >opportunity to filter them before everyone sees them. This fellow just happened >to be one of the three who I had marked for review. > >Okay that's all about the state of the p2p-hackers mailing list. I'm impressed >with the quality (not to mention quantity) of subscribers that are currently >registered, and I'm hoping that something will spark a really productive and >creative exchange. > >Regards, > >Zooko > >[1] http://sourceforge.net/mailarchive/forum.php?forum_id=7702 > >--- > zooko.com >Security and Distributed Systems Engineering >--- >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers _________________________________________________________________ 享用世界上最大的 Web 电子邮件系统 —— MSN Hotmail。 http://www.hotmail.com/cn From oskar at freenetproject.org Sun Mar 24 05:45:01 2002 From: oskar at freenetproject.org (Oskar Sandberg) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] steam? In-Reply-To: ; from bram@gawth.com on Sat, Mar 23, 2002 at 06:19:46PM -0800 References: <004401c1d279$2ed0dbc0$2002a8c0@jdarcyvaio> Message-ID: <20020324144618.L17009@sandbergs.org> On Sat, Mar 23, 2002 at 06:19:46PM -0800, Bram Cohen wrote: > Jeff Darcy wrote: > > > > All content distribution tools seem to > > > fall into one of three general categories - > > > > > > a) Akamai > > > > > > b) BitTorrent > > > > > > c) Napster > > > > I think that's way too simplistic, Bram. Where, for example, would Freenet > > fit into that, or MNet? > > Freenet isn't a content distribution system, it's an anonymity > system. An elephant isn't gray, it's an animal. Freenet is very much a content distribution system. It's performance goals are different, since the primary interest is data survivability from censorship rather than efficiency or speed, but that doesn't change the fact that it is system that is meant for distributing content. > MNet falls squarely into the Napster group. Wasn't Napster a search engine? It seems to me that calling Napster, Gnutella, Fasttrack etc content distribution systems is a stretch - they are content locator systems. <> -- Oskar Sandberg oskar@freenetproject.org From zooko at zooko.com Sun Mar 24 06:03:01 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie Message-ID: I can think of three kinds of distributed data-moving network: 1. File-sharing network. The file exists canonically in one place, it gets transferred to another. E.g. (the file-moving part of) Napster, et al. Not to mention FTP. 2. Content distribution network. The file exists canonically in one place, it gets spread around, cached, error-corrected, streamed and so forth. This is basically application-level multicast. E.g. BitTorrent, Swarmcast, Digital Fountain, those research projects that I mentioned in my web log. [1] 3. Emergent file system. The file exists canonically in the virtual file system, and *not* in any one physical place. E.g. Eternity, Freenet, FreeHaven, Mojo Nation, Mnet, CFS. This is what I call a "universal file space" and what Adam Back recently called a "file surface". Justin Chapweske's "WebRAID/Content-Addressable Web" blurs the line between 2 and 3 by allowing secure caching and mirroring. BitTorrent could easily blur that line by having peers continue to offer files even long after they've finished downloading them. The hard part is how the new downloaders finds those peers or those web-caches long after they've finished downloading or caching the file. Going the other way, Mnet could blur the line between 3 and 2 by offering "hints" that tell which specific nodes are suspected by the hinter of having specific blocks. Those hints would come with the block id. From the perspective of Mnet, this would be a performance optimization on top of the virtual, emergent file system. I guess that Freenet would not be willing to do that kind of optimization because it conflicts with the Freenet approach to anonymity and censorship- resistance. Regards, Zooko [1] http://zooko.com/log.html#2002-03-18 --- zooko.com Security and Distributed Systems Engineering --- From ethan.eade at duke.edu Sun Mar 24 08:05:01 2002 From: ethan.eade at duke.edu (Ethan Eade) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] RE: Node Identity in a P2P network In-Reply-To: <20020324112804.D345F3FD5B@capsicum.zgp.org> Message-ID: <000001c1d34d$d5f106d0$2cdf1098@ethan> > The general issue of secure, distributed naming is almost impossible to solve. > Probably you would do better to abandon human-readable names and just let the > "names" be public keys. Each name owner would hold the corresponding private > key and prove ownership whenever necessary (by signing data with the private > key). This provides fully unforgeable names which would be well suited as node > identifiers. Trying to make them be human readable is an awful can of worms. The problem with this is that some applications rely on human readable names as a lookup for nodes. For instance, on a Chord based network, imagine that the only key/value pairs stored at nodes are name/hashed-ip pairs -- so that given "Ethan" a node hashes it, looks that up in the distributed index, gets some other hash id (say the hash of "Ethan"'s ip) and then looks up that in the network to get to "Ethan". The problem isn't being sure that it's "Ethan" once I get there, but rather keeping a false "Ethan" from registering in the first place, since a falsely registered "Ethan" would keep all inquirers of "Ethan" from ever finding the real one in a lookup. Essentially, the act of registering under a name (inserting the pair hash_of["Ethan"]/hash_of[evil_ip] into the index) is a denial of service attack against the 'rightful' owner of "Ethan" -- and 'rightful' can't even have a network wide meaning, since the nodes making up the network can be a completely distinct set over two different sessions! While I can see that there's no way to effect a network wide name-ownership, I think there's probably a way to do it on a limited basis -- that is, preventing some denial of service. ~Ethan Eade From justin at chapweske.com Sun Mar 24 08:46:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie References: Message-ID: <3C9E02B7.1070501@chapweske.com> hints == bloom filters ? > > Going the other way, Mnet could blur the line between 3 and 2 by offering > "hints" that tell which specific nodes are suspected by the hinter of having > specific blocks. Those hints would come with the block id. From the > perspective of Mnet, this would be a performance optimization on top of the > virtual, emergent file system. > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From zooko at zooko.com Sun Mar 24 09:19:01 2002 From: zooko at zooko.com (Zooko) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: Message from Justin Chapweske of "Sun, 24 Mar 2002 10:45:43 CST." <3C9E02B7.1070501@chapweske.com> References: <3C9E02B7.1070501@chapweske.com> Message-ID: Justin Chapweske wrote: > > hints == bloom filters ? That is one possibility, but more sophisticated than what I meant. I just meant changing Mnet from "Here's the ID of a block. Go search the emergent file system to find the actual block.", to "Here's the ID of a block. Oh, and here's a hint: the node with public key XYZ at IP address 123.45.67.8 probably has the block.". I'm not convinced that this kind of trick is necessary since with the new Distributed Hash Tables (e.g. Chord) searching the virtual file system for a block given its id is pretty darn fast, and can be combined with fetching, caching, and replication a la CFS. But it's nice to know that such performance optimizations are possible on top of an emergent file system, should we need them in the future. Anyway, the original point was that it is a fuzzy distinction between "content distribution networks" in which the file has a "canonical" physical location but it gets cached in other places and "emergent file systems" in which the file has no "canonical" physical location but you can have a hint about a physical location. Regards, Zooko --- zooko.com Security and Distributed Systems Engineering --- > > Going the other way, Mnet could blur the line between 3 and 2 by offering > > "hints" that tell which specific nodes are suspected by the hinter of having > > specific blocks. Those hints would come with the block id. From the > > perspective of Mnet, this would be a performance optimization on top of the > > virtual, emergent file system. From justin at chapweske.com Sun Mar 24 09:29:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available References: <016d01c1d303$46a29fb0$650a000a@gojovaio> Message-ID: <3C9E0CC0.2080903@chapweske.com> Why is it fileMD5 and audioSha1 ? This doesn't seem very consistent to me. -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From lucas at worldos.com Sun Mar 24 10:53:01 2002 From: lucas at worldos.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] RE: Node Identity in a P2P network In-Reply-To: <000001c1d34d$d5f106d0$2cdf1098@ethan> Message-ID: There are only two ways to have unique nyms. One, self-verifying nyms using asymetric keys. Two, human readable names issued by an authority that never issues a given nym more than once. The second case doesn't work if there is more than one authority, hence ICANN exists for the sake of being the One True Scope. Any successful one-true-scope scheme ends up having the namespace crowded to the point of uselessness. Either names become more and more arbitrary, like "petstore25533444666.com", or they fork into multiple sub-namespaces, as with email names rooted on unique ISP domains. As names become more arbitrary they get less human readable. As namespaces fork they create more collisions, e.g. between joe@aol.com and joe@proctorandgamble.com. Uniqueness and human readability are mutually exclusive. === Given that ICANN is a fundamentally stupid idea, the details of its policies do matter. So can someone explain to me: 1) why there can't be an infinite number of top level domains? 2) why ICANN's blistering incompetence seems to be a permanent thing? - Lucas From bram at gawth.com Sun Mar 24 11:11:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network In-Reply-To: <63329eca2d0c5eb1c37c844b424ab6bb@remailer.privacy.at> Message-ID: Anonymous wrote: > The general issue of secure, distributed naming is almost impossible > to solve. Probably you would do better to abandon human-readable names > and just let the "names" be public keys. Or, you could abandon keys and let the names be urls, which has tons of interoperability benefits. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sun Mar 24 11:21:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: <3C9E02B7.1070501@chapweske.com> Message-ID: Justin Chapweske wrote: > hints == bloom filters ? Hey Justin, what's that URL you had which explained bloom filters? For those not in the know, bloom filters are a way of compressing down a list of hash values to be not so large. Unfortunately all they can do is a constant factor of 5-10, so their benefits on anything where space isn't the bottleneck are minimal. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From bram at gawth.com Sun Mar 24 11:23:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: Message-ID: Zooko wrote: > Justin Chapweske's "WebRAID/Content-Addressable Web" blurs the line > between 2 and 3 by allowing secure caching and mirroring. BitTorrent > could easily blur that line by having peers continue to offer files > even long after they've finished downloading them. BitTorrent does that now, although the end user can stop it from uploading whenever they want. A bunch of people left finished downloaders running during the recent slashdotting. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From nobody at remailer.privacy.at Sun Mar 24 11:55:01 2002 From: nobody at remailer.privacy.at (Anonymous) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: Lucas Gonze asks: > Given that ICANN is a fundamentally stupid idea, the details of its > policies do matter. So can someone explain to me: > 1) why there can't be an infinite number of top level domains? Obviously, because there are not an infinite number of human-readable strings, since the human brain is finite. If you're asking why we have a policy of a relatively small number of TLD's (on the order of a dozen, or a few hundred if you count the countries) rather than a number in the millions, presumably it is because of the desire to maintain a hierarchical structure. If you allowed virtually any word or trademark as a TLD then they would essentially not be domains at all, they would just be names. You would have URLs like http://Microsoft, etc. This might be arguably better, but it is unarguably a significantly different approach from the traditional DNS, and so would be a radical departure from the present system. > 2) why ICANN's blistering incompetence seems to be a permanent thing? The answer to this is equally obvious. To a very close approximation, every organization is incompetent. It's just that some are better able to hide it than others. ICANN is in a very public position and its incompetence is highly visible. Also, Bram Cohen writes regarding names: > Or, you could abandon keys and let the names be urls, which has tons of > interoperability benefits. This essentially means letting ICANN (and its successors) solve the problem. It is not yet clear that this is a feasible long term solution. From wesley at felter.org Sun Mar 24 12:18:01 2002 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: Message-ID: on 3/24/02 1:20 PM, Bram Cohen at bram@gawth.com wrote: > Justin Chapweske wrote: > >> hints == bloom filters ? > > Hey Justin, what's that URL you had which explained bloom filters? I'm not Justin and I don't even play him on TV, but here's the link I usually give people: http://www.cap-lore.com/code/BloomTheory.html Wes Felter - wesley@felter.org - http://felter.org/wesley/ From lucas at worldos.com Sun Mar 24 14:16:01 2002 From: lucas at worldos.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network In-Reply-To: Message-ID: I asked: > > 1) why there can't be an infinite number of top level domains? > and anonymous replied: > Obviously, because there are not an infinite number of human-readable > strings, since the human brain is finite. Is there a need to have an administrative body select which strings are considered human readable? > If you're asking why we have a policy of a relatively small number > of TLD's (on the order of a dozen, or a few hundred if you count the > countries) rather than a number in the millions, presumably it is because > of the desire to maintain a hierarchical structure. If you allowed > virtually any word or trademark as a TLD then they would essentially > not be domains at all, they would just be names. You would have URLs > like http://Microsoft, etc. > > This might be arguably better, but it is unarguably a significantly > different approach from the traditional DNS, and so would be a radical > departure from the present system. I have heard this reasoning before and it is a complete mystery to me. There would still be a hierarchy, it would just have a broader base. As far as I can tell the only barrier is in realizing that there is no barrier. From blanu at bozonics.com Sun Mar 24 18:50:02 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network In-Reply-To: <000201c1d2d5$c29e3620$2cdf1098@ethan> Message-ID: > One might wish to have the equivalent of "accounts" in a p2p > network, that restrict the identity one is allowed to use. For > instance, in a p2p decentralized version of instant messaging, where any > node enters and leaves the network on the order of minutes (or seconds,) > how can the network maintain persistency about "accounts" -- if I > connect and register as "Ethan" and then sign off, what's to keep my > archnemesis from registering as "Ethan" when he signs on? I'd like to add my vote to the applicability of pet names to this problem, as well as offer a bit more detail on a pet name-based user interface for IM. Some IM clients already offer pet name features. The name which you bind someone to in your buddy list doesn't have to be their identifier in the system. In ICQ, for example, users have numbers while buddy lists have names associated with those numbers. So ICQ has already got the pet name thing covered to the point that it fixes the problem you mention above. The centralized aspect to ICQ naming is that tying an entity to an identity is done by the centralized ICQ server and uses password authentication. The P2P way would of course use public keys and so users could generate their own identifiers without the need for a central server. But the UI would be the same. Bind some long string you copy and paste to a name. The part where some new UI techniques would be good would be for the situation where an identifier you don't know contacts you. IM clients currently ask you whether to put them in your buddy list or not. In the pet names paper it was suggested that entities should be able to suggest what name they would like to be bound to. This gives you a hint of who someone is (or might be), and also saves you some typing. Of course, there is a good tool for nasty social engineering as well. All I think we need UI-wise for this is to have a graphical distinction between provisional and certified name bindings and a formal ritual for upgrading from provisional and certified. When you attempt to authoritatively bind a name, the UI should say look, are you sure this isn't an imposter? If you're sure then you can change that status of the name binding. This is really a small UI tweak, but I think would help out greatly in the security of IM systems, P2P or otherwise. From blanu at bozonics.com Sun Mar 24 18:50:03 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available In-Reply-To: <016d01c1d303$46a29fb0$650a000a@gojovaio> Message-ID: > We're considering XML-RPC gto enable a wider set of > programmatic options for submitting metadata and rating > metadata and files. But we'll also continue to support > the plain form-POST method, perhaps with extra switches > to "confirm-immediately" or "submit-anonymously". I would of course encourage you to look at the Tristero XML-RPC APIs for this, http://tristero.sourceforge.net/search.html and to give feedback on how they need to be modified to fit well with your needs. Bitzi is a prime example of the sort of service that we want the Search set of APIs to work with. We've received a lot of good feedback from the folks at NeuroGrid, Alpine, and plex as to ways to improve the APIs and I think it would be great if they could be made to fit Bitzi's needs as well. From blanu at bozonics.com Sun Mar 24 18:50:05 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: Message-ID: > I'm not convinced that this kind of trick is necessary since with the new > Distributed Hash Tables (e.g. Chord) searching the virtual file system for a > block given its id is pretty darn fast, and can be combined with fetching, > caching, and replication a la CFS. So I've been thinking of the replication problem in Chord and in distributed filesystems like MNet, and a big problem, I think, is churn. You can't have reliability with nodes dropping out all of the time. I think that the solution to this is to have a Chord network where each node is actually a cluster of nodes in a fully-connected graph. Each cluster manages the keyspace of the virtual node it is a part of and is charge of managing the replication of data across the nodes in the cluster to ensure its reliability. This is related to the existing replication methods for Chord, but has the added provision that the nodes take an active part in the replication of data and in monitoring the status of the nodes around them. This system is even compatible with typical n+1, n+2, ... n+k Chord replication. All you have to do is make the k nodes in a particular area of the ring all know about each other rather than just the next one in the chain. This also ties in with Byzantine Chord, where having nodes in an area of the ring all know about each other ensures that no single node can lie about which node is next in the ring, thus keeping nodes from properly joining that area of the ring. From tzoompy at cs.washington.edu Sun Mar 24 23:47:01 2002 From: tzoompy at cs.washington.edu (Stefan Saroiu) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] RE: Node Identity in a P2P network In-Reply-To: <000001c1d34d$d5f106d0$2cdf1098@ethan> Message-ID: <20020324233906.V18159-100000@magnesium.cs.washington.edu> On Sun, 24 Mar 2002, Ethan Eade wrote: > > The general issue of secure, distributed naming is almost impossible > to solve. > > Probably you would do better to abandon human-readable names and just > let the > > "names" be public keys. Each name owner would hold the corresponding > private > > key and prove ownership whenever necessary (by signing data with the > private > > key). This provides fully unforgeable names which would be well > suited as node > > identifiers. Trying to make them be human readable is an awful can of > worms. > > The problem with this is that some applications rely on human readable > names as a lookup for nodes. For instance, on a Chord based network, > imagine that the only key/value pairs stored at nodes are name/hashed-ip > pairs -- so that given "Ethan" a node hashes it, looks that up in the > distributed index, gets some other hash id (say the hash of "Ethan"'s > ip) and then looks up that in the network to get to "Ethan". The > problem isn't being sure that it's "Ethan" once I get there, but rather > keeping a false "Ethan" from registering in the first place, since a > falsely registered "Ethan" would keep all inquirers of "Ethan" from ever > finding the real one in a lookup. Essentially, the act of registering > under a name (inserting the pair hash_of["Ethan"]/hash_of[evil_ip] into > the index) is a denial of service attack against the 'rightful' owner of > "Ethan" -- and 'rightful' can't even have a network wide meaning, since > the nodes making up the network can be a completely distinct set over > two different sessions! > While I can see that there's no way to effect a network wide > name-ownership, I think there's probably a way to do it on a limited > basis -- that is, preventing some denial of service. > ~Ethan Eade > I think we're confusing the issues a bit. In Chord a name (a handle to an object) dictates where the object is stored. But this need not be the case necessarily (it's not in Gnutella). The issue of "Uniqueness and human readability are mutually exclusive" seems to remain true, independent of whether names are used to identify where objects are stored (although Fen Labalme post earlier a message about Stuart Haber's work - which claims to solve this problem, 3rd paper here http://www.star-lab.com/stuart/dig-time-stamping.html. I haven't read more than the abstract). Notice that in DNS the problem is partially solved. Here at UW, I can't register the name www.mit.edu. Why? - Because I can only register names of type *.washington.edu. However, I CAN register any *.washington.edu (well it's up to the sysadmins here to stop me). --Stefan > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From tzoompy at cs.washington.edu Mon Mar 25 00:06:01 2002 From: tzoompy at cs.washington.edu (Stefan Saroiu) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] kinds of distributed file thingie In-Reply-To: Message-ID: <20020324235029.C18159-100000@magnesium.cs.washington.edu> > I think that the solution to this is to have a Chord network where each > node is actually a cluster of nodes in a fully-connected graph. Each > cluster manages the keyspace of the virtual node it is a part of and is > charge of managing the replication of data across the nodes in the cluster > to ensure its reliability. This is related to the existing replication > methods for Chord, but has the added provision that the nodes take an > active part in the replication of data and in monitoring the status of the > nodes around them. This system is even compatible with typical n+1, n+2, > ... n+k Chord replication. All you have to do is make the k nodes in a > particular area of the ring all know about each other rather than just the > next one in the chain. This also ties in with Byzantine Chord, where > having nodes in an area of the ring all know about each other ensures that > no single node can lie about which node is next in the ring, thus keeping > nodes from properly joining that area of the ring. > I completely agree with you. There is an even simpler reason of why the nth node (the destination) must know about all the replicas in the system, if they are either the next k, or the k nodes in a cluster, etc... In traditional Chord, when I search an object X, I keep sending requests from one peer to the next, following fingers. When I get to the destination, I keep querying the next k successors for a replica of the object. Problems: a. I need to know k. b. I need to know that the replication scheme in Chord is "follow next k successors." c. k seems to be a magic number in the system In other words, the replication scheme in Chord is not "client transparent" (my client needs to know about a, b, c above). In contrast in DNS, I don't need to know about much. I ask for a name and I get a list of IPs. Select any one from the list, and I'm good to go. The change you propose would get rid of all a, b, c above, in that I would just be handled a list of IP addresses where the content is replicated. Again, select any and I'm good to go. --Stefan > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From gojomo at usa.net Mon Mar 25 13:23:02 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available References: <016d01c1d303$46a29fb0$650a000a@gojovaio> <3C9E0CC0.2080903@chapweske.com> Message-ID: <03a101c1d442$da07d140$650a000a@gojovaio> Justin writes: > Why is it fileMD5 and audioSha1 ? This doesn't seem very consistent to me. You're right; it's an oversight. I think we'll correct in the direction of 'audioSha1'. - Gojomo From justin at chapweske.com Mon Mar 25 16:50:01 2002 From: justin at chapweske.com (Justin Chapweske) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available References: <016d01c1d303$46a29fb0$650a000a@gojovaio> <3C9E0CC0.2080903@chapweske.com> <03a101c1d442$da07d140$650a000a@gojovaio> Message-ID: <3C9FC594.30505@chapweske.com> This probably isn't the forum to debate such things, but "file" makes more sense to me than "audio" for the hashes.....I know how to hash a file, but how does one hash sound? Gordon Mohr wrote: > Justin writes: > >>Why is it fileMD5 and audioSha1 ? This doesn't seem very consistent to me. >> > > You're right; it's an oversight. I think we'll correct in the > direction of 'audioSha1'. > -- Justin Chapweske, Onion Networks http://onionnetworks.com/ From gojomo at usa.net Mon Mar 25 17:25:01 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available References: <016d01c1d303$46a29fb0$650a000a@gojovaio> <3C9E0CC0.2080903@chapweske.com> <03a101c1d442$da07d140$650a000a@gojovaio> <3C9FC594.30505@chapweske.com> Message-ID: <013101c1d475$b38478b0$2a01a8c0@golden> Ah, OK. I thought you were just talking about the hash-abbrieviation capitalization difference. The field 'audioSha1' is only calculated for MP3 files, and is the hash of the file AS IF any ID3 tags were not present. So it can be considered a sort of 'audio-part-only' hash. As such, it may be useful to detect MP3s that are the same except for ID3 tags. (It is of course not useful for detecting audio-similarity, like an acoustic fingerprint could.) The actual file's SHA1 value is not reported as a metadata field, because it is considered the ~identity~ that we're describing. It has to be read from the urn:bitprint: identifier inside the "rdf:about" attribute. It's the part before the '.'. For example, one line of the example ticket on the referenced page is: To: Sent: Monday, March 25, 2002 4:49 PM Subject: Re: [p2p-hackers] ANNC: Bitzi Ticket XML Web Service Available > This probably isn't the forum to debate such things, but "file" makes > more sense to me than "audio" for the hashes.....I know how to hash a > file, but how does one hash sound? > > Gordon Mohr wrote: > > Justin writes: > > > >>Why is it fileMD5 and audioSha1 ? This doesn't seem very consistent to me. > >> > > > > You're right; it's an oversight. I think we'll correct in the > > direction of 'audioSha1'. > > > > > > > -- > Justin Chapweske, Onion Networks > http://onionnetworks.com/ > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers From svanegmond at tinyplanet.ca Mon Mar 25 21:19:01 2002 From: svanegmond at tinyplanet.ca (Stephen van Egmond) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list In-Reply-To: References: Message-ID: <20020326051816.GB11892@tinyplanet.ca> Zooko (zooko@zooko.com) wrote: > Also, a lot of people talk on IRC channels on irc.openprojects.net, and once > they've made their points in IRC chat, they are less likely to type the idea in > again and flesh it out to post to a list. At least, that's true for me. I've > recently started making a conscious effort to post to > mnet-devel@lists.sourceforge.net [1] whenever I say something that would be > of interest to that list. Classic knowledge-management problem. Is there a bot hanging out in IRC, or one we could drop in? A place we can put good logs? Hell, a wiki? I'm conversant in p2p concepts, and haven't written, well, any code at all, but I'm all about information communities, and solving this kind of problem is my favourite thing to do. - Steve From gojomo at usa.net Mon Mar 25 22:15:01 2002 From: gojomo at usa.net (Gordon Mohr) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list References: Message-ID: <01e801c1d49e$2f69d1f0$2a01a8c0@golden> Zooko wrote: > Also, a lot of people talk on IRC channels on irc.openprojects.net, and once > they've made their points in IRC chat, they are less likely to type the idea in > again and flesh it out to post to a list. At least, that's true for me. I've > recently started making a conscious effort to post to > mnet-devel@lists.sourceforge.net [1] whenever I say something that would be > of interest to that list. Which IRC channels at openprojects.net would you recommend? - Gojomo From wesley at felter.org Mon Mar 25 22:18:01 2002 From: wesley at felter.org (Wes Felter) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list In-Reply-To: <20020326051816.GB11892@tinyplanet.ca> Message-ID: on 3/25/02 11:18 PM, Stephen van Egmond at svanegmond@tinyplanet.ca wrote: > Zooko (zooko@zooko.com) wrote: >> Also, a lot of people talk on IRC channels on irc.openprojects.net, and once >> they've made their points in IRC chat, they are less likely to type the idea >> in >> again and flesh it out to post to a list. At least, that's true for me. >> I've >> recently started making a conscious effort to post to >> mnet-devel@lists.sourceforge.net [1] whenever I say something that would be >> of interest to that list. > > Classic knowledge-management problem. Is there a bot hanging out in > IRC, or one we could drop in? A place we can put good logs? Hell, a > wiki? I'm conversant in p2p concepts, and haven't written, well, any > code at all, but I'm all about information communities, and solving this > kind of problem is my favourite thing to do. There are a variety of bots, but they can't solve the problem that people generally don't want to read IRC logs. Mailing lists are fundamentally different than IRC, because people seem to put effort into composing messages to lists. Wes Felter - wesley@felter.org - http://felter.org/wesley/ From bram at gawth.com Mon Mar 25 23:16:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Peek-a-Booty wiki Message-ID: Peek-a-Booty's peer discovery is an interesting problem. Me, Jeremy Avnet and Jonathan Moore have some interesting ideas about it, which are written up in this work in progress - http://wiki.haven.sh/index.php/PeekabootyResourceDiscovery -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From sam at neurogrid.com Tue Mar 26 00:08:01 2002 From: sam at neurogrid.com (Sam Joseph) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] state of the p2p-hackers mailing list References: <20020326051816.GB11892@tinyplanet.ca> Message-ID: <3CA02CCC.2090107@neurogrid.com> I think there are different reasons to have mailing lists, chat rooms and wikis. One day maybe we'll have a tool that can in some way automatically integrate the links between them. In the meantime people are welcome to use the NeuroGrid Wiki: http://www.neurogrid.net/devwiki/wikipages/P2P-Hackers The system is not being backed up at the moment, but I'm going to connect it up to CVS in the next few days, so all data will be archived. Feel free to write notes here, create new pages etc. CHEERS> SAM Stephen van Egmond wrote: >Zooko (zooko@zooko.com) wrote: > >>Also, a lot of people talk on IRC channels on irc.openprojects.net, and once >>they've made their points in IRC chat, they are less likely to type the idea in >>again and flesh it out to post to a list. At least, that's true for me. I've >>recently started making a conscious effort to post to >>mnet-devel@lists.sourceforge.net [1] whenever I say something that would be >>of interest to that list. >> > >Classic knowledge-management problem. Is there a bot hanging out in >IRC, or one we could drop in? A place we can put good logs? Hell, a >wiki? I'm conversant in p2p concepts, and haven't written, well, any >code at all, but I'm all about information communities, and solving this >kind of problem is my favourite thing to do. > >- Steve >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers > > From burton at openprivacy.org Tue Mar 26 15:31:02 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? Message-ID: <871ye6rjp4.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone working on P2P onion routing? I have been thinking of building a JXTA service to do this (in my infinite time of course). I think this is an interesting area but a lot of tech needs to land first. Specifically node based quality of service (any work here (probably based on reputation)). Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ I'm intercontinental when I eat french toast... - Beck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8oQSHAwM6xb2dfE0RAlSDAJ0Qv05gryo/Ekz3FRF5upAHkO/fLgCdHKOQ pfGwlcCVVPd/dOpDApdJ4eU= =0E4b -----END PGP SIGNATURE----- From tutschku at informatik.uni-wuerzburg.de Tue Mar 26 15:37:02 2002 From: tutschku at informatik.uni-wuerzburg.de (Dr. Kurt Tutschku) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <871ye6rjp4.fsf@openprivacy.org> Message-ID: <5.1.0.14.0.20020327004245.021e8e78@nero.informatik.uni-wuerzburg.de> Hi Hermann, was meinst du zu Onion-Routing? Cheers Kurt At 15:30 26.03.2002 -0800, you wrote: >-----BEGIN PGP SIGNED MESSAGE----- >Hash: SHA1 > > >Anyone working on P2P onion routing? I have been thinking of building a JXTA >service to do this (in my infinite time of course). > >I think this is an interesting area but a lot of tech needs to land first. >Specifically node based quality of service (any work here (probably based on >reputation)). > >Kevin > >- -- >Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, >burtonator@acm.org ) > Location - San Francisco, CA, Cell - 415.595.9965 > Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ > >I'm intercontinental when I eat french toast... > - Beck > > > >-----BEGIN PGP SIGNATURE----- >Version: GnuPG v1.0.6 (GNU/Linux) >Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt > >iD8DBQE8oQSHAwM6xb2dfE0RAlSDAJ0Qv05gryo/Ekz3FRF5upAHkO/fLgCdHKOQ >pfGwlcCVVPd/dOpDApdJ4eU= >=0E4b >-----END PGP SIGNATURE----- >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers ---- Dr. Kurt Tutschku Institute of Computer Science Am Hubland 97074 Wuerzburg Germany Tel.: +49-931-8886641 FAX.: +49-931-8886632 mailto:tutschku@informatik.uni-wuerzburg.de or mailto:kurttutschku@hotmail.com http://www-info3.informatik.uni-wuerzburg.de/staff/tutschku -------------- next part -------------- An HTML attachment was scrubbed... URL: http://zgp.org/pipermail/p2p-hackers/attachments/20020326/77b64b79/attachment.htm From lucas at worldos.com Tue Mar 26 15:51:01 2002 From: lucas at worldos.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <871ye6rjp4.fsf@openprivacy.org> Message-ID: Sure. WorldOS did P2P onion routing back in '00. Nobody every really bought the need for onion routing, and after all this time I'm not sure that I do myself. > Anyone working on P2P onion routing? I have been thinking of building a JXTA > service to do this (in my infinite time of course). > > I think this is an interesting area but a lot of tech needs to land first. > Specifically node based quality of service (any work here (probably based on > reputation)). > > Kevin From lucas at worldos.com Tue Mar 26 15:51:02 2002 From: lucas at worldos.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <5.1.0.14.0.20020327004245.021e8e78@nero.informatik.uni-wuerzburg.de> Message-ID: Think of a recursively defined stack, where pushing means to wrap a layer around the old stack, and popping means to unwrap a layer. See, e.g., the stuff on "stack routing" at http://www.worldos.com/technology/routing.php On Wed, 27 Mar 2002, Dr. Kurt Tutschku wrote: > Hi Hermann, > > was meinst du zu Onion-Routing? > > Cheers > Kurt > > At 15:30 26.03.2002 -0800, you wrote: > >-----BEGIN PGP SIGNED MESSAGE----- > >Hash: SHA1 > > > > > >Anyone working on P2P onion routing? I have been thinking of building a JXTA > >service to do this (in my infinite time of course). > > > >I think this is an interesting area but a lot of tech needs to land first. > >Specifically node based quality of service (any work here (probably based on > >reputation)). > > > >Kevin From blanu at bozonics.com Tue Mar 26 15:51:04 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <871ye6rjp4.fsf@openprivacy.org> Message-ID: > Anyone working on P2P onion routing? I have been thinking of building a JXTA > service to do this (in my infinite time of course). > > I think this is an interesting area but a lot of tech needs to land first. > Specifically node based quality of service (any work here (probably based on > reputation)). Tarzan is working on this. They presented at IPTPS. I believe the Invisible IRC Project is moving their mixnet towards onion routing as well. Roger has some fascinating work on quality of service in mixnets which he presented at Financial Crypto and O'Reilly P2P #2. From blanu at bozonics.com Tue Mar 26 17:01:01 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: Message-ID: > Think of a recursively defined stack, where pushing means to wrap a layer > around the old stack, and popping means to unwrap a layer. See, e.g., the > stuff on "stack routing" at http://www.worldos.com/technology/routing.php Onion routing certainly has this layer thing, but it is specifically layered so that each layer can only be seen by one node in the chain due to public key encryption. From michael.iles.lists at sympatico.ca Tue Mar 26 18:41:01 2002 From: michael.iles.lists at sympatico.ca (Lists) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <871ye6rjp4.fsf@openprivacy.org> Message-ID: <001001c1d538$b071fdf0$0200a8c0@toque> What's the advantage of onion routing? Onion routing (where the _messages_ hold their own routing information) and gnutella routing (where the _nodes_ hold routing tables tracking the messages) are both unable to recover from the loss of a single node in the routing chain. It seemed to me like JXTA had addressed this through their hybrid 'endpoint routing protocol' where a message could hold a list of desired hops, or it could simply hold its desired destination, and any node along the way could ask for additional route choices from a peer router. Wouldn't onion routing be a step backwards for JXTA? Mike. -----Original Message----- From: p2p-hackers-admin@zgp.org [mailto:p2p-hackers-admin@zgp.org] On Behalf Of Kevin A. Burton Sent: March 26, 2002 6:30 PM To: p2p-hackers@zgp.org Subject: [p2p-hackers] P2P Onion Routing? -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Anyone working on P2P onion routing? I have been thinking of building a JXTA service to do this (in my infinite time of course). I think this is an interesting area but a lot of tech needs to land first. Specifically node based quality of service (any work here (probably based on reputation)). Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ I'm intercontinental when I eat french toast... - Beck -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8oQSHAwM6xb2dfE0RAlSDAJ0Qv05gryo/Ekz3FRF5upAHkO/fLgCdHKOQ pfGwlcCVVPd/dOpDApdJ4eU= =0E4b -----END PGP SIGNATURE----- _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers From chris at connelly.net Tue Mar 26 18:43:01 2002 From: chris at connelly.net (Chris Connelly) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? References: Message-ID: <001501c1d552$813715b0$1701a8c0@LAPDANCE> Why do you think this? I'd think the world especially needs something like onion routing with ZKS's Freedom gone (in it's old incarnation anyways), and when privacy is so blatantly disreguarded so often? _______________________________ Chris Connelly PGP: 3E47 4B48 A05C 8E47 09DE A1F7 58CC 8BEB 128D 9436 PGP Key ID 0x128D9436 (pgp.mit.edu) ----- Original Message ----- From: "Lucas Gonze" To: Sent: Tuesday, March 26, 2002 3:34 PM Subject: Re: [p2p-hackers] P2P Onion Routing? > Sure. WorldOS did P2P onion routing back in '00. Nobody every really > bought the need for onion routing, and after all this time I'm not sure > that I do myself. > > > Anyone working on P2P onion routing? I have been thinking of building a JXTA > > service to do this (in my infinite time of course). > > > > I think this is an interesting area but a lot of tech needs to land first. > > Specifically node based quality of service (any work here (probably based on > > reputation)). > > > > Kevin > > _______________________________________________ > p2p-hackers mailing list > p2p-hackers@zgp.org > http://zgp.org/mailman/listinfo/p2p-hackers > From chris at connelly.net Tue Mar 26 18:48:01 2002 From: chris at connelly.net (Chris Connelly) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? References: <001001c1d538$b071fdf0$0200a8c0@toque> Message-ID: <002101c1d553$379afab0$1701a8c0@LAPDANCE> From lucas at gonze.com Tue Mar 26 19:15:01 2002 From: lucas at gonze.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <001501c1d552$813715b0$1701a8c0@LAPDANCE> Message-ID: On Tue, 26 Mar 2002, Chris Connelly wrote: > Why do you think this? I'd think the world especially needs something like > onion routing with ZKS's Freedom gone (in it's old incarnation anyways), and > when privacy is so blatantly disreguarded so often? > Well, like a lot of things related to privacy and security, people don't really want it. They may say they want it, but it doesn't really matter. In the time I spent evangelizing WorldOS I never got reactions of any kind to the onion routing aspects. There's a portion of onion routing features that has since been absorbed by both SOAP 1.2 and Jxta, and that's the fact that the message path is a stack which grows as the path is established and which is held within the message. The alternative is to have return paths stored as local state within each intermediary; local state consumes resources that can only be freed by tossing out return paths. So stack/onion routing eliminates the problem of premature message expiration, which is a very good thing. But neither SOAP 1.2 nor Jxta formed their stack recursively so the privacy enhancement of being able to encrypt the stack was lost. As a side note, I was mainly interested in onion routing because of the way it enables reputation systems. Onion routing blinds a node to any node but its immediate neighbors, so enforces the one-to-one relationships that make reputation work. ...hence Kevin's original point about the intersection with reputation. (and assuming that a Reptile/Jxta hookup is probably what he's after.) - Lucas From lucas at gonze.com Tue Mar 26 19:23:01 2002 From: lucas at gonze.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <001001c1d538$b071fdf0$0200a8c0@toque> Message-ID: True, but there's never a way to re-route a broken return path without having the endpoint ID be public knowledge. Whether that's ok is an application decision, not a protocol feature. > What's the advantage of onion routing? Onion routing (where the > _messages_ hold their own routing information) and gnutella routing > (where the _nodes_ hold routing tables tracking the messages) are both > unable to recover from the loss of a single node in the routing chain. > > It seemed to me like JXTA had addressed this through their hybrid > 'endpoint routing protocol' where a message could hold a list of desired > hops, or it could simply hold its desired destination, and any node > along the way could ask for additional route choices from a peer router. > > Wouldn't onion routing be a step backwards for JXTA? > > Mike. From lucas at gonze.com Tue Mar 26 19:25:02 2002 From: lucas at gonze.com (Lucas Gonze) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: Message-ID: Actually, symetric encryption is fine, since decryption/unwrapping is handled by the same node that did the encryption. On Tue, 26 Mar 2002, Brandon Wiley wrote: > > > Think of a recursively defined stack, where pushing means to wrap a layer > > around the old stack, and popping means to unwrap a layer. See, e.g., the > > stuff on "stack routing" at http://www.worldos.com/technology/routing.php > > Onion routing certainly has this layer thing, but it is specifically > layered so that each layer can only be seen by one node in the chain due > to public key encryption. From bram at gawth.com Tue Mar 26 23:55:02 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: Message-ID: Lucas Gonze wrote: > True, but there's never a way to re-route a broken return path without > having the endpoint ID be public knowledge. Whether that's ok is an > application decision, not a protocol feature. A fundamentally more robust way of doing anonymous receiving than reply block chaining is Private Information Retrieval. Unfortunately PIR schemes aren't *quite* there yet - http://citeseer.nj.nec.com/beimel01informationtheoretic.html My intuition says the above can be greatly improved upon in terms of runtime, hopefully that will happen within the next few years. -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes From cloudcn at hotmail.com Wed Mar 27 03:05:01 2002 From: cloudcn at hotmail.com (cloud cloud) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: Can you explain more clearly the difference role between"key"and"url"?I think key is more world wide persistent and unique than url,which makes it more suitable in p2p systems. >From: Bram Cohen >Reply-To: p2p-hackers@zgp.org >To: p2p-hackers@zgp.org >Subject: Re: [p2p-hackers] Node identity in a dynamic peer network >Date: Sun, 24 Mar 2002 11:10:19 -0800 (PST) > >Anonymous wrote: > > > The general issue of secure, distributed naming is almost impossible > > to solve. Probably you would do better to abandon human-readable names > > and just let the "names" be public keys. > >Or, you could abandon keys and let the names be urls, which has tons of >interoperability benefits. > >-Bram Cohen > >"Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers _________________________________________________________________ 享用世界上最大的 Web 电子邮件系统 —— MSN Hotmail。 http://www.hotmail.com/cn From blanu at bozonics.com Wed Mar 27 03:05:03 2002 From: blanu at bozonics.com (Brandon Wiley) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <001001c1d538$b071fdf0$0200a8c0@toque> Message-ID: > What's the advantage of onion routing? Onion routing (where the > _messages_ hold their own routing information) and gnutella routing > (where the _nodes_ hold routing tables tracking the messages) are both > unable to recover from the loss of a single node in the routing chain. > > It seemed to me like JXTA had addressed this through their hybrid > 'endpoint routing protocol' where a message could hold a list of desired > hops, or it could simply hold its desired destination, and any node > along the way could ask for additional route choices from a peer router. The purpose of onion routing is that the nodes in the chain don't know the sender and recipient. JXTA's routing does not accomplish this. From cefn.hoile at bt.com Wed Mar 27 03:32:02 2002 From: cefn.hoile at bt.com (cefn.hoile@bt.com) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Node identity in a dynamic peer network Message-ID: URLs can use the web infrastructure to be guaranteed unique. However, = they are usually intended as a human readable means of specifying a = resource.=20 Keys on the other hand are usually generated by an automated process = which does not lend itself to human readability. Of course, URLs can be generated from an automated process and not be (fully) human readable, such as the session ids used to manage = transactions with a web server when cookies are turned off. Equally, Keys can be generated from URLs. The debate over the use of keys recently has been about the addressing = of resources in specific systems. The desire is to enable humans to store = and relocate references to resources, and it is hard to distinguish between references when there is no human readable element. Generally key management tools are used to address these problems, = enabling humans to interact at a more satisfactory semantic level (i.e. 'the key = for Bram's shared file digest'), and storing and recalling the less human-readable keys.=20 Is there any way in which this sort of tool could be generalised?=20 What would it have to be able to do in order to solve the problem for multiple resource repositories?=20 Hope this makes things less cloudy for you. Cefn -----Original Message----- From: cloud cloud [mailto:cloudcn@hotmail.com] Sent: 27 March 2002 02:43 To: p2p-hackers@zgp.org Subject: Re: [p2p-hackers] Node identity in a dynamic peer network Can you explain more clearly the difference role between"key"and"url"?I = think key is more world wide persistent and unique than url,which makes = it=20 more suitable in p2p systems. >From: Bram Cohen >Reply-To: p2p-hackers@zgp.org >To: p2p-hackers@zgp.org >Subject: Re: [p2p-hackers] Node identity in a dynamic peer network >Date: Sun, 24 Mar 2002 11:10:19 -0800 (PST) > >Anonymous wrote: > > > The general issue of secure, distributed naming is almost = impossible > > to solve. Probably you would do better to abandon human-readable = names > > and just let the "names" be public keys. > >Or, you could abandon keys and let the names be urls, which has tons = of >interoperability benefits. > >-Bram Cohen > >"Markets can remain irrational longer than you can remain solvent" > -- John Maynard Keynes > >_______________________________________________ >p2p-hackers mailing list >p2p-hackers@zgp.org >http://zgp.org/mailman/listinfo/p2p-hackers _________________________________________________________________ =CF=ED=D3=C3=CA=C0=BD=E7=C9=CF=D7=EE=B4=F3=B5=C4 Web = =B5=E7=D7=D3=D3=CA=BC=FE=CF=B5=CD=B3 =A1=AA=A1=AA MSN Hotmail=A1=A3 http://www.hotmail.com/cn _______________________________________________ p2p-hackers mailing list p2p-hackers@zgp.org http://zgp.org/mailman/listinfo/p2p-hackers From arma at mit.edu Wed Mar 27 12:53:01 2002 From: arma at mit.edu (Roger Dingledine) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <871ye6rjp4.fsf@openprivacy.org>; from burton@openprivacy.org on Tue, Mar 26, 2002 at 03:30:15PM -0800 References: <871ye6rjp4.fsf@openprivacy.org> Message-ID: <20020327155158.S6832@moria.seul.org> On Tue, Mar 26, 2002 at 03:30:15PM -0800, Kevin A. Burton wrote: > Anyone working on P2P onion routing? I have been thinking of building a JXTA > service to do this (in my infinite time of course). > > I think this is an interesting area but a lot of tech needs to land first. > Specifically node based quality of service (any work here (probably based on > reputation)). There are a number of people working in this direction. But we'd certainly welcome more. I'm pushing the original Onion Router team into looking at ways of broadening the infrastructure to look at volunteer nodes; but don't expect any useful code from that anytime soon. As Brandon mentioned, you should take a look at Mike Freedman's Tarzan paper [1]. It's not onion routing per se, but I think you're being broad enough in what you mean that Tarzan definitely counts. [1] http://www.cs.rice.edu/Conferences/IPTPS02/182.pdf There are a number of nasty problems that come up when scaling decentralized anonymity systems to many volunteer nodes. For instance, paranoid designers like me start freaking out about pseudospoofing --- how can you be sure that half of your 'volunteers' aren't being run by the same person? Another example is how to get people the list of nodes they can use. If we've got an anonymizing infrastructure of 10000 nodes, and each user downloads information for 50 of them at random and builds a path out of four of those 50, then each user's path probably won't overlap by more than one node with any other path. So just looking at two hops of the path will 'bridge' each mix node, revealing which message was sent by whom. That is, a passive adversary watching senders and then watching the onion routing network can trivially link all messages. (PIR techniques, which Bram mentioned, may be a good route to solving this.) The issue you raised above is also a key point --- if there are 10000 volunteers registered, how on earth do you find a path through several of them that will actually succeed right now? We talk at length about node reliability, and how to build reputation systems to track which nodes perform well, in our FC02 paper [2] and the preceeding paper at IH4 [3]. [2] http://freehaven.net/doc/casc-rep/casc-rep.pdf [3] http://freehaven.net/doc/mix-acc/mix-acc.pdf Accompanying the reputation system problem are more hard issues. For instance, the adversary now has incentive to provide reliable service so he can read more traffic: reliability and anonymity can be at odds too. We have a short position paper [4] in the proceedings of CFP2002 on "Reputation in Privacy Enhancing Technologies", describing a few lessons learned in designing reputation systems for two anonymity systems, namely the remailer network and Free Haven. [4] http://freehaven.net/doc/cfp02/cfp02.html We're working on more stuff currently, but that should keep you full for a while. Let me know if you've got any questions, --Roger From burton at openprivacy.org Thu Mar 28 01:21:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <001501c1d552$813715b0$1701a8c0@LAPDANCE> References: <001501c1d552$813715b0$1701a8c0@LAPDANCE> Message-ID: <87lmcdjbgx.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Chris Connelly" writes: > Why do you think this? I'd think the world especially needs something like > onion routing with ZKS's Freedom gone (in it's old incarnation anyways), and > when privacy is so blatantly disreguarded so often? ZKS was great... but was hard to setup and certainly not P2P. Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ 2600 Magazine says Ford sucks: http://www.fordreallysucks.com/more_info.html -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8ouAuAwM6xb2dfE0RAvi8AJ41ncvr4zzEVi+741UMVC6iXOKfywCfSj9X CCDLkR9zyXowu8qq2G6jHx4= =8Ba+ -----END PGP SIGNATURE----- From burton at openprivacy.org Thu Mar 28 01:23:01 2002 From: burton at openprivacy.org (Kevin A. Burton) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] P2P Onion Routing? In-Reply-To: <001001c1d538$b071fdf0$0200a8c0@toque> References: <001001c1d538$b071fdf0$0200a8c0@toque> Message-ID: <87hen1jbe2.fsf@openprivacy.org> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 "Lists" writes: > It seemed to me like JXTA had addressed this through their hybrid 'endpoint > routing protocol' where a message could hold a list of desired hops, or it > could simply hold its desired destination, and any node along the way could > ask for additional route choices from a peer router. > > Wouldn't onion routing be a step backwards for JXTA? Onion routing wouldn't be a requirement in any sense. And an onion route can be recovered if it fails and a new path choosen. Kevin - -- Kevin A. Burton ( burton@apache.org, burton@openprivacy.org, burtonator@acm.org ) Location - San Francisco, CA, Cell - 415.595.9965 Jabber - burtonator@jabber.org, Web - http://relativity.yi.org/ For evil to win, is for good men to do nothing. - Winston Churchill. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.0.6 (GNU/Linux) Comment: Get my public key at: http://relativity.yi.org/pgpkey.txt iD8DBQE8ouCVAwM6xb2dfE0RAqCOAKC7JOBjn4KuSdP6Cmcr6OxlXgYCLACfYzpn KSg5VgMWKgp8xbkUSGQd4vM= =oPgq -----END PGP SIGNATURE----- From bram at gawth.com Sun Mar 31 22:13:01 2002 From: bram at gawth.com (Bram Cohen) Date: Sat Dec 9 22:11:44 2006 Subject: [p2p-hackers] Choking algorithms Message-ID: With the latest rewrite of the choking algorithm in BitTorrent, I can finally say it's mature, meaning I can honestly say it's a good starting point if you're going to write your own. You can see the code here - http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/bittorrent/BitTorrent/BitTorrent/Choker.py?rev=1.1&content-type=text/vnd.viewcvs-markup -Bram Cohen "Markets can remain irrational longer than you can remain solvent" -- John Maynard Keynes