Gnutella2?
Anenga writes "A Windows (and somewhat WINE compatible) Gnutella client, Shareaza, has released a public preview of its next version which includes a re-designed Gnutella protocol they call "Gnutella2".
Gnutella2 (or "G2") dumps the Gnutella broadcast model and uses a new global searching method with UDP connections. It also features compression to limit hub-to-hub (G2 Ultrapeers) bandwidth, Tiger Tree Hashing etc. Shareaza has released a small description of the revised protocol here, but plans to release a full spec to the GDF after the release of v1.7 Final. Gnutella2, which is really a revised Gnutella protocol, will also be free and open for anyone to use in their clients. Shareaza and G2 may give Gnutella - an open and free P2P protocol which has been
struggling to keep up with the times against
Kazaa, eDonkey and other P2P
spin-offs - the stability and power it needs to attract the closed and
commercial FastTrack Network users when or if the network folds."
now, the few complete files i get will be corrupted.
I've tried the beta release and G2 hubs operate faster than the G1 hubs. I was able to get faster and larger searches. If only the other clients included supportf for G2 in the future. Better not be Coke II!
I remember when I first tried Gnutella clients, they were awful and i've never been able to download a thing off of one on my Windows or Linux PC, so I finally broke down and used Kazaa, which works fine. Hopefully G2 downloads things better, or else it won't catch on.
Anything that is a move to keep a variety of standards out the in the P2P world is a positive move, stopping record companies finding a way to stop the whole movement by blocking a single protocol, (a la Napster). The more the better.
Help the scientists free the world from the evil curse of the dracula
I've been working with the JXTA project for a bit now, and they seem to be taking a very nice approach to designing a p2p network that is implementation independant (can be implemented on different platforms, devices, etc.). Besides gnutella (and g2), and JXTA, are there other open P2P networks out there? And if there are, what's the best project?
"What we have here, is a failure to communicate." - Cool Hand Luke
Anyone here find it just a wee bit ironic that a postabout BMG and their so-called "copy protection" (*chuckle*) is followed immediately by a rather technical article on a new, faster, better, low-density P2P client?
Hell, they haven't even managed to shut the _first_ version down!
Cheers,
Bowie J. Poag
I have been using Shareaza for quite some time now and this will be a much needed improvement. One thing that Gnutella has lacked is a faster systems for searching and sharing. I still don't think it will be able to compete with the easy to use GUI of Kazaa or Morpheus. Either way it is a decent step in the right direction for P2P sharing.
[n8.r0n] http://petesweb.spymac.net/
if people tested out this network by trading only BMG files at first. Have to beta test and all though I suppose.
---
When you come to a fork in the road, take it! --Yogi Berra--
Is the Gnutella Web Caching System. It allows clients to find other gnutella peers without any sort of central gnutella server.
Let's hope that this gnew version of gnutella will be better and more scalable than the previous one.
Points from the gnutella2.com site:
Level One: A New Protocol
Gnutella2 introduces a flexible new protocol to support current and future P2P technologies. Packets are compact binary trees of named data items, which allow multi-vendor information nesting and augmentation, selective digital signing and other exciting features. Existing data structures can be modified and improved without disrupting deployed software, and advanced topics such as UNICODE support are handled in a uniform manner.
Level Two: A New Data Transport Architecture
Gnutella2 provides two interdependent data transport mechanisms: reliable compressed TCP streams, and an unreliable and semi-reliable UDP transport provider. The combination of these two systems allow higher level G2 constructs to take maximum advantage of network conditions to deliver data packets quickly and efficiently, with or without assured delivery, within bandwidth requirements and without unnecessary overhead.
Level Three: A New Set of Base Services
Gnutella2 takes full advantage of the first two levels to deliver an exciting new set of distributed peer-to-peer services. Controlled global object searching is implemented using an iterative walker approach, with selective out of band response delivery and translation. Combined with an abstract component interest/response query model, this system goes beyond what is available in any other P2P platform. The Gnutella Addressing System (GAS) provides the ability to reach arbitary nodes based on a known identifier, regardless of their connection method.
Level Four: A New Implementation Standard
One of the problems facing the legacy Gnutella network was the varying level of support for critical network features in different clients. The Gnutella2 Standard requires clients to implement the first two levels completely, as well as the dual transport providers with some form of intelligent bandwidth control, 1-bit universal QHT, simple search response, basic metadata (at minimum), simple query language, link compression, root tigertree as the primary URN, HTTP/1.1, partial transfer and sharing. If able to operate as a hub, the full set of generic routing rules must be supported. Support for G1 is recommended but not required.
CLICK ME!
Ever since I've been using Broadband (Optimum Online yeah baby!), eDonkey has won me over vs. Kazaa(lite).
Alhough eDonkey needs a little more work than Kazaa to operate, the file hashing/segmented downloads/no leeching is far better than Kazaa, plus the amount of file corruptions I get using Kazaa is way too much (especially with very large files). I've also started trying Overnet, but still have loads of downloads I'm clearing through the Donkey (Yes I have tried using the donkey downloads for Overnet, but only half register in the download tab).
I've tried using Gnutella/Gnucleus on numerous occasions, bit given up due to a lack of being able to do anything with it compared to the other P2P programs... I just hope Gnutella2 will become a viable option for me to use it.
Are you local? There's nothing for you here!
It's going to be dificult to compare shareza's performance to edonkey and fastrack because of the difference in size, especailly since at the moment shareza is the only gnutella client to use G2.
What are Shareza's long term business plans ?, are they going to take advantage of the network by selling their user's distributed proccesing power like sharman networks are planning to ?, or postion themselves as a legal media distribution system once DRM and Palladium are implemented ?.
New legal loopholes, number of law suits hopefully will be reduced. Bugs fixed, patched up and worked a fix for delaying litigation for as long as possible. TODO, find more legal loopholes that will not put an end to p2p, serialz, crackz and bibtex entries also to be added to sharing.
Analytic & algebraic topology of locally Euclidean meterization of infinitely differentiable Riemmanian manifold
Post 3, Gnutella 2.
so I do win! God, life is beautiful!
Does anyone actually use P2P networks for legal uses?!?!?!?!?!? e.g. not mp3/porn..
If so, can you list what you use it for?
Get it while you can! Before the RIAA/MPAA go hound our Republican war-mongering big-business-loving government into launching an airstrike on the servers.
I'm a engineer at Lime Wire LLC so I can debunk much of this submission. Shareaza's Gnutella2 isn't so much the second iteration of Gnutella - instead, think of it as a improved Gnutella . In fact, the improvements were actually proposed by Lime Wire LLC (consult the GDF and look for messages about 'GUESS'). The GUESS protocol is a UDP based protocol we developed to allow for Gnutella network crawls/walks. We introduced it for public comment on the GDF *before* releasing it because we understand that Gnutella, as a open protocol, needs support from all Gnutella developers. I'm not sure what exactly Shareaza has implemented (because they HAVE NOT released the specs yet), but it sounds a lot like GUESS.
So this isn't so much Gnutella2 as a improved Gnutella. Perhaps one day it will evolve into Gnutella2 more formally, but at the moment this talk of Gnutella2 is premature.
smd4985
"Gnutella2, which is really a revised Gnutella protocol..."
"And like that
I wonder how this client will perform for people behind firewalls? Many firewalls are setup to deny UDP traffic because most Internet activity is TCP and having UDP open has been unnecessary up to this point.
I wonder if this will halt the spread of Gnutella2? With P2P, it's all about getting as many people online as possible.
is OpenFT from the giFT project.. as people may recall, giFT was originally an open implmentation of parts of the FastTrack protocol, used by Kazaa, et al. This was an year ago, and KaZaA was not at all happy about this, so they updated a few times to break giFT (see KaZaA version 1.33).
So, some of giFT's developers decided to abandon fasttrack, and make their own protocol, OpenFT. giFT went from "giFT is not FastTrack" to "giFT: Internet File Transfer". This protocol, primarily written by jasta of gnapster fame, has been development for the last ~8 months. A publically released version of giFT with OpenFT is not available yet, but right now, the CVS version works quite well.. even in some ways better than FastTrack does.
There are also some great advantages to giFT. First of all, it enforces a seperation between the client and the network code. giFT is a daemon that handles most of the interaction with the outside world. There are also a multitude of giFT frontends, which are very easy to write, as no network code has to be created. giFT is also modular.. you can put in bridges or even full support to other protocols and networks.
Sure, it's useable, but it's horrific. Kazaa's is aweful, eDonkey's just blows and WinMX, urgh, don't get me started.
Admitially I never really investigated Gnutella after trying the original Nullsoft version. The UI was ok, if a little plain, but the time it took to hook up to a bunch of stable nodes, the slow download time and frequency of dropped downloads just put me off.
So really, all i'm asking is that whilst you're concentrating on making an excellent protocol, please don't employ a 7 year old with a crayon to do the UI. Hell, I'd happily help out on an OSS project, however I can't use VC++ to save my life and most people wouldn't like submissions on Visual Basic frm's - i'll probably end up standing on the sidelines shouting but having no-one listen.
There are a few examples of technically inferior applications that do better than others simply because their UI is clean, consistent and works. Lets have that, please!
Avantslash - View Slashdot cleanly on your mobile phone.
Anybody who knows want to comment on whether Shareaza is loaded with spy/adware? Thanks in advance.
Comment removed based on user account deletion
coming from a company who installs spyware? I don't use p2p filesharing apps, but I've had to clean several machines of users who do. Although I fully understand the desire to rob people blind through their own stupidity; I'm in technical support for crying out loud, I just can't see how anything that comes from you guys(or any other company willing to put that sort of trash on a person's machine) could be truthful.
When will somebody make a p2p gateway which will allow different p2p protocol to interacted at a different layer and interact with one another despite whatever p2p protocl they are using
The (solvable) problems with Gnutella:
Bandwidth Usage (for searches)
Search results. You only get about 4-7 hops. Assuming 4 hops & 4 non-redundant connections per node, that means you are only searching about 256 nodes. Being able to search everyone would make Gnutella for more useful for less-common files.
Fifo queuing. You may have been requesting a file for the past 24 hours, but someone that just requested a file may get lucky, and take what should have been your spot.
Messages. We need messages to tell people that slow nodes downloading from our node gets disconnected, that you are 2nd in the queue, etc.
Upload settings. Each node should be disconnected after a set period of time to prevent slow nodes from causing bottlenecks, or RIAA employees from abusing the limited open slots.
Bandwith Min/Max for Uploads/Downloads. A limit on the min/max speed for each file download/uploaded, and a min/max for the TOTAL of all downloads/uploads.
Dynamic determination of REAL IP (if behind NAT with dynamic globally valid IP).
Solution to the 'PUSH' fiasco. Is there a way that 2 firewalled nodes can connect to a third (non-firewalled) party to open the connection, then tranfer data directly? I don't think so, but worth including here.
Any more?
Slashdot gets worse every day... Pipedot: News for nerds, without the corporate slant
The whole point of a p2p network is not to share files but to not get caught sharing files.
Last February I got a bigfoot letter from my ISP, Rogers, who had been contacted by the Canadian equivalent to the MIAA, whatever it's called.
I was sharing tons of stuff, 8,000 mp3s, on DalNet and they wanted me to stop. What bothers me is they never contacted ME, they went straight to my ISP and tried to get me kicked off the Internet.
The letter from Rogers said you're in violation etc, stop now etc, or else etc.
So, I stopped.
This close call ruined my career on Dalnet where I had built quite a rep, and trashed my source of free music.
And not popular music either - ancient stuff you cant get anymore, like Robert Crumb and his Cheap Suit Serenaders. Buy THAT at your local CD shop...
Since then the point has been made moot by the fact that my cable modem has been capped at about a FIFTH of it's previous speed. (I am investigating DSL)
However - the crux of the whole matter is this - the record companies hired people to go on the internet and score music for them. Then these people, who, and this is crucial, have the IP of the music source, use that IP to run down the source down and then use legal means to try and get that person kicked off the internet.
IT DOESN'T MATTER HOW FANCY YOUR PROTOCOL IS OR HOW GOOD YOUR CRYPTOGRAPHY IS, IF THEY CAN GET YOUR IP YOUR SCREWED.
I have NEVER seen a p2p system address this issue.
It's Christmas everyday with BitTorrent.
GIVE ME MORE! waste your moderator points on me!
i have plenty of karma to spare! muhahahaha!
keep it simple.
Eg , source or binaries for various programs. Unlikley I admit but the potential is there. P2P is basically the old archie protocol combined with ftp , whereas archie searched for stuff and told you where it was but didn't go get it , P2P does both.
Gnucleus has been a solid Gnutella client for me.
They are also working on GnucDNA a component for building your own P2P applications.
http://www.kubuntu.org/
At last, a straight answer from Limewire people about spyware.
Sorry guys, but I use Mac OS 9 on my high-bandwidth connection and X on dialup. I never have to deal with LimeWire spyware, and the company produces the most prominent Mac filesharing client.
Without Limewire, good filesharing implementations are few and far between, and I really appreciate them being around. Because otherwise, there'd be almost nobody.
This guy is a troll. He's pushing IE, closed source, propriatary standards, and the domination of MS over the W3C and standards committees. He's saying that product "foo" is better than your product to try to sting you a bit, and then bashing the GDF, which *developed* the stuff he's lauding.
Don't bite.
May we never see th
For those Windows people who prefer an open-sourced alternatives, there is an eMule ed2k network client.
2c
3.243F6A8885A308D313
For OS X, there's a nice GNUtella client called Acquisition . It's got a clean interface, does find files, has resumable transfer, works, etc.
I've been able to download a couple of DivX/AVI files off of it, as well as some apps. Gnutella's probably the best protocol we have on the Mac, at this time, and hearing complaints about the others (WinMX for Windows, or KazaA, etc.) I really don't think it's that bad.
If a number of people are extensively working in the same area of knowledge, it quite often leads to a simultaneous and independent discoveries of the same or very similar ideas. This is especially true on the frontiers of the research, where an initial idea is merely a seed used to start an iterative refining process, which results in an 'optimal' solution.
:-/
The situations like this require great deal of tact from either party not to blame each other in stealing the idea, especially if there was a cooperation happening in some form.
Your comment seems to be biased and based solely on the fact that someone else gained the publicity you were aiming for. Too bad
3.243F6A8885A308D313
Standartization takes a loooot of time, and involves a lot of politics. Participating and contributing people want the credit, whether we as general public like it or care about it or not (take a look at IKE for example). If not given - some of them tend to stall the process. It is not a technology issue, it's a basic pshycology.
I think it is perfectly legitimate practice to produce a proprietory protocol, put it through internal revision with number of people you know and then release to the public. How you would call it - it's a different issue, but - hey - Gnutella2 is as good name as any.
3.243F6A8885A308D313
Well I assume if your posting on /. you are familiar with CVS? Go to this page and grab a copy of the source. All you need to compile is the java sdk and the ant build tool.
no leeching is far better than Kazaa
I seriously doubt that. Any current "no leeching" mechanisms I've seen are severely flawed and rely on trusted remote code.
People who whine and bitch that people are bypassing them are ignoring the fact that the design is fundamentally wrong. You cannot trust code on another computer. Period. It *will* be broken.
It is possible to build a trust web (where you have metered trust, instead of just a binary "trusted" or "not trusted" a la PGP). Have each user generate a public/private key pair. Have each person maintain a list of trusted users. These users are identified by their public keys. "Trust values" are assigned to each user in the list-holding user's trust list. The scale is arbitrary -- maybe "100" means trust a lot and "1" means trust a little, and "0" means no trust. Trust is generally positive (more on that later).
When you want to determine "absolute trust" of a user, you run out and download the trust lists of all the users from them in your trust list (this spans only two hops out on the web of trust...you could go further, though I think this is sufficient). Person can grant absolute trust to person B as following: (points of trust A gives B in A's local trust list)/(total points of trust A gives A's local trust list)* (points of trust A has in our local trust list).
Then, attackers like the RIAA will be excluded from the network of trust, having low or no trust values, as they hand out corrupted files.
Trust lists can be redownloaded whenever. Cache 'em for weeks if you want.
Clients could automatically add a point of trust per data unit downloaded succesfully from a remote client...then, if it's a bad download, the local user could strip all trust away.
Trust could be used for ranking priorities to let people download from you, determining which copy of a file is "authentic" and which is bogus, etc.
Other possibilities: the reason we don't allow negative trust or blacklists -- only whitelists -- is because it's usually fairly easy to regenerate a new IP, and this results in bloating attacks against users maintaing blacklists. If a user can present something that "costs" them something to obtain, like a VeriSign cert or other "expensive" (i.e. can't regenerate on your computer easily) proof of identity (doesn't have to be your RL name -- could be a signed cert endorsing a 'nym from Zero Knowledge), then give them automatically a certain number of points of trust (client configurable). Why? Because it's much less likely that they're running out and buying a new Verisign cert for each attack. They're opening themselves up to blacklisting.
You could purge year-old entries from your local trust list to stay up to date...oh, there's tons of possible tweaks.
The trust network simply sits on top of another P2P network. It does not require that users not download from users with zero trust -- it simply provides some extremely useful information which is essential to implementing strong antileech/anti network attack protections, or what have you. It is also very difficult to attack. PGP is much more vulnerable, since you just need one stupid person in your web of trust to okay someone, their binary trust bit flips to 1, and they're in your web. If you don't trust someone much, and they give someone else a little tiny bit of trust...that person is only very slightly trusted.
Drawbacks:
My analysis of this approach has found only two drawbacks. First, there is some disk and memory overhead to store cached trust information locally. Gnutella clients already store IPs for much of the network, so it shouldn't be prohibitive, though -- we don't have to handle the whole network, just *trusted* users.
The second one is that letting people download your trust list -- crucial to the functioning of the system -- can leak some information. It means that you "trust" some user on the network. If that user provides nothing but, say, child porn, anyone on the trust network has circumstantial evidence that you have downloaded child porn. Of course, you could have granted the person trust for any number of other reasons, but it is a small amount of information leakage, and worth mentioning.
I welcome comments.
May we never see th
So, if I read this right - let's say for instance that amazon.com is an affiliate. And I make a webpage with a lot of information about baking cookies, including a link to a book at amazon.com with a lot of good recipes.
A LimeWire/TopMoxie user surfs my site and likes it. Wants to buy the book. Clicks the link to buy it.
Now, if I read this right TopMoxie will pop up when I try to buy the book and ask if the user would like to redirect the bonus from the sale to LimeWire.
Is my understanding of this correct or not?
Weaselmancer
rediculous.
I want archie back. Current web-based FTP search engines suck. I like the command line search...pop in the name of a software package like openoffice, and it spits back several sites.
After a lot of work, six months ago I got an archie client compiling. Took some work on the source, but got it up. Then I took another two weeks to find a working archie server. It was the last public one, I'm fairly certain.
Two months after that, it went down. I was probably the only person that used it in ages, and probably the admins were wondering what was going on.
May we never see th
Download link http://download.shareaza.com:8825/Shareaza1701.exe seems impossibly slow -- I'm getting 276 bytes per sec on my DSL connection. For anyone who wants to check out the 1.7 prerelease, here's a mirror:
http://nstrom.chaosnet.org/Shareaza1701.exe
So does this mean I get more pr0n, or less pr0n?
Finally we'll be able to trade pictures of naked women across the internet.
I've run this by one of the gtk-gnutella developers, who's said that this seems like a good idea.
May we never see th
A major problem for me with Gnutella is anonymity. I would like to be able to download and upload files without revealing my IP number.
:-(
I suppose it is debatable whether this is solvable without changing Gnutella's properties beyond recognition.
I know Freenet is an alternative, and I havn't tried the latest version, but I think Freenet would have problems implementing a search function like Gnutella's.
Some ideas of how to run something like Gnutella anonymously are:
* using something like the Anonymizer. However, I'd have to trust the anonymizer
* Running over IPv6, getting an IPv6 address that is harder for the bad guys to track/convert to IPv4 than using a normal IPv4 address.
* Designing a protocol where data travels through several clients on its way from source to destination. Each client doesn't know if the next client is the final destination or not, the clients basically act as routers and only know the next hop to take on its way to its destination. This is similar but not equivalent to FreeNet (no encrypted resource identifiers, each node holds exactly the data which it serves (not encrypted)).
This would be less efficient than current Gnutella. It would require some reasonably efficient self-organizing routing scheme (this seems like the most difficult part of an implementation). But it could hopefully be more efficient than Freenet.
Personally, I would value anonymity enough to sacrifice a fair amount of performance.
Comments?
Having just switched over from Windows, I searched in vain for a Kazaa port. I guess there's Kazaa Lite. What do you recommend?
I haven't seen anyone mention the potential of abusing the UDP search extension as a massive DDoS reflector. Simply send a query for something very common, with a faked source address on the packet, to as many Ultrapeers as possible. (I'm assuming that Shareaza implemented the GUESS extension, as many people have suggested.)
The documentation for GUESS is not reassuring:
This totally ignores the fact that the only way to determine which node sent the packet is to use the source address on the UDP packet! Am I missing something here? Am I misreading the documentation?
Ever signed anyone's PGP key? There are 4 levels of trust. (at least with GPG) Check your facts.
Copyright Violation:"theft, piracy"::Anti-Trust Violation:"thermonuclear price terrorism"<-Overly dramatic language.
True (I wasn't aware of this, and I'm not sure that there's actually *support* for this in any actual implementation), but not useful for what I'm talking about. It's still much too rough-grained.
May we never see th
Gnutella is useless due to its limited substring search. I have to perform multiple searches for the same kind of file because of it.
>80 column hard wrapped e-mail is not a sign of intelligent
>life
>Have each person maintain a list of trusted users.
>Clients could automatically add a point of trust per data unit downloaded
This is where your scheme falls down. In a real p2p net you constantly
interact with people you have not communicated with before. You
don't exchange files with the same people often enough for "you
scratch my back, I'l scratch yours" to give a worthwhile benifit.
The traffic required to gather the information needed to keep track
of individual users is more of a burden than leeches.
When user A uploads to user B only they know that it happened,
if user A says he uploaded but user B says he didn't then who do you trust?
You end up with a circular problem finding a critical mass of people
you trust to rely on.
There is also the privacy/incrimination issue of tracking individual
users uploads and downloads.
I thought about this a lot and tried to create algorithms for working
out how much to trust someone.
I'm mainly trying to come up with a workable distributed effective anti
leech system. The only solution that seems workable to me is for the
users to form groups. The group members trust each other. People who
want the same sort of files will group together, groups of pr0nsters,
electronica fans, ebook people etc.
When people in group X have sent you more bytes than you have sent to them,
you give people from group X priority in your upload queue.
Group members are mostly people who upload a lot so being friends with a
whole group generally works out ok.
You need some crypto so that group members can prove their membership
and people can't falsly claim to be a member of a group that uploads
a lot.
The implementation details will need tweaking after some actual s/w
is written. My current vision is that a group grows from a single
member who holds the group private key. The founder grants membership
to people who upload to him. Group members send reccomendations to
the founder for new members. When the group grows large it may be
necessary to spread the private key to several members.
I imagine a successful group having a couple of hundred members.
When someone is given upload priority because they are in a group
the uploader says "you get to jump the queue because groups members
x,y,z have uploaded to me". That information is shared and used
within the group. To get rid of people who stop uploading after
joining a group, the members form a new group with a new key
every month or so, they descided amongst themselves who gets invited
into the new group based on who uploaded within the group and
who enhanced the groups reputation with the rest of the net.
This is also necessary when the keyholder stops using the net/formats his drive etc.
People can be a member of multiple groups and new one are allways forming. You can only credit your uploads to a couple of groups
so obviously you credit the groups that you have benifited from
being a member of and drop membership of useless groups.
With many people only being online part time and the need
to find colleagues on dynamic ips to exchange info, things
like forming a new group out of an old one may take several
weeks.
Can someone in the know explain Tiger Tree Hashing, and what advantages it might have? Thanks
Moderation Totals: Flamebait=2, Troll=1, Redundant=1, Insightful=6, Overrated=1, Underrated=1, Total=12. (not mine)
In a real p2p net you constantly interact with people you have not communicated with before.
:-(
But if you have a 200 entry trust list, and all the people on there have a 200 entry trust list, that's a pretty sizeable chunk of data. It isn't just those that you have to interact with.
The traffic required to gather the information needed to keep track of individual users is more of a burden than leeches.
Take the above scheme...200 lists, refreshed on at most a weekly basis...that isn't *that* much. A gnutella client generates more than that with search broadcasts in a short period of time.
When user A uploads to user B only they know that it happened, if user A says he uploaded but user B says he didn't then who do you trust?
Using files was just an idea, one of the many sources of deriving trust automatically. Originally my idea was to manually grant trust -- "Wow, this guy's serving me this great file! I'm giving him some points!". However, I suspect that people are more likely to be willing to do active negative moderation ("These files are fakes -- I'm stripping the guy of all the trust I gave him") and let the client slowly increase trust. It also makes it difficult for someone *cough* MPAA to serve deliberately corrupted files, since their goal is to serve tiny corrupted slices and damage large files -- to gain trust, they have to serve large chunks of data. There is no required, direct link between files downloaded and trust gained. Furthermore, the only person listened to is the person *granting* the trust. He is under no onus to grant trust if he downloads a file -- this isn't "credit" or "money", it's "trust". He could have a client that doesn't trust anyone except those he manually marks.
There is also the privacy/incrimination issue of tracking individual issue of tracking individual users uploads and downloads.
Yes, I mentioned that. It was some of some concern, but the fact that trust can derive from other sources helps obscure it. There's no log of transferred files ever moved around. The best you know is that Person A knows of Person B, and likely engaged in some transaction with them. Hell, they could have chatted with them and liked them and jacked their trust.
I thought about this a lot and tried to create algorithms for working out how much to trust someone
Same here, though my interest lies more in the field of improving resistance of P2P networks to organized outside attack, as the RIAA/MPAA have been hiring firms to do. The robust antileech stuff is a bonus that I suspect some people will be interested in.
The only solution that seems workable to me is for the users to form groups. The group members trust each other. People who want the same sort of files will group together, groups of pr0nsters, electronica fans, ebook people etc. When people in group X have sent you more bytes than you have sent to them, you give people from group X priority in your upload queue.
Actually, rather similar to what I'm doing in essence. My approach is a bit more fuzzy (outward spreading weakening webs of trust), since I'd like to automate as much as possible, which I feel is important for scalability reasons. People tend to interact with those that hae similar interests.
You need some crypto so that group members can prove their membership and people can't falsly claim to be a member of a group that uploads a lot.
[Nods] similar to my conclusions, and my design follows yours here. Note: one drawback of any auth system that I have a small amount of concern over is that suddenly, people are storing a standardized piece of data that has lots of value to crackers on their computer -- their keypair. I could see nasty worms erupting aimed at grabbing keypairs.
The implementation details will need tweaking after some actual s/w is written. My current vision is that a group grows from a single member who holds the group private key. The founder grants membership to people who upload to him. Group members send reccomendations to the founder for new members. When the group grows large it may be necessary to spread the private key to several members.
Again we're similar. A few differences -- I tried to avoid discrete trust level issues -- "I trust you" or "I don't", but no middle ground. You may not trust everyone that gets into the group -- an issue with PGP, for instance. Second, there is no single private key in what I'm proposing -- no person has rights to anything other than their own trust list. Third (this may in particular be interesting, since it could be better either way), with your system trust is transitive. If User A is in Group B, and User C is in Group B, then A and C both trust each other. I allow one way trust -- I can trust Bob the Enormous Fileserver Admin, though he may not trust me.
Your idea sounds almost like a distributed version of Direct Connect. If you can get a userlist, it's like a distributed server...
Thanks for the feedback and posting the ideas. There are precious few people interested in security issues on P2P (despite the fact that P2P needs security more than most areas), and it's really good to talk to someone else interested in the area. Most P2P types like "quick patch" solutions.
May we never see th
BitTorrent has real, working leech resistance, with no fancy certs at all. It just uses tit-for-tat.
While it may make you feel authoritative to simply dismiss the technical problems of decentralized trust, that doesn't make them go away - Noone has to date gotten a decentralized cert system to work, period, and I predict noone will within the next decade.
What technical problems are you concerned with?
I have one major advantage -- I suspect that most people doing decentralized trust care about whether someone can be trusted absolutely or not. I'm willing to say "this person is a little trusted" even if there's not a lot of ground to go on (because someone you trust trusts them) or "this person is not trusted" even if they could be (the db doesn't have to be complete at each node). It's okay to have a certain error margin, because this is just used to assist the primary program. That would, I imagine, free me from the nastiest constraint involved...
May we never see th
Interesting proposal, 0x0d0a. It's quite similar to the trust metric work I've been pursuing for my PhD thesis, and which is implemented in Advogato.
In general, I find the attack-resistance of your proposal to be sound. However, because your horizon only goes out to a horizon of two, it's an easier problem to solve than the general trust case. If you try to extend your system to more hops, you'll probably find that the trust values fade very fast. This was one of the less expected results I found when I implemented the eigenvector-based diary ratings at Advogato.
In any case, I encourage you to look at my trust metric work, and to use the code I've released as well as the trust graph available at Advogato. This will probably help you test and develop your ideas further.
Here's a url with links to most of the other stuff I'm talking about: http://www.levien.com/free/tmetric-HOWTO.html
LILO boot: linux init=/usr/bin/emacs
Bram, how does the tit-for-tat system work?
Brad Neuberg
That's explained in the protocol document.
I actually remember e-mailing you about this back in the day, how because I was on a super high bandwidth line I ended up having upload traffic an order of magnitude greater than my download traffic.
It's not entirely up to your program either as many connections these days are asymetric. Most cable will pull 1.5mbps or more down when not congested but is capped at 128k up.
Wow. Thanks for your time reviewing this.
because your horizon only goes out to a horizon of two
The horizon of two isn't a hard limit -- it might be extended to, say, three, or even be adaptive. However, I strongly suspect that trying to maintain any sort of local cache of an entire P2P network is a losing cause, unless distribution of the thing was a bit smarter (come to think of it, since there are public keys involved, this data can be signed...hmm, interesting, though it still might eat a lot of storage space).
the trust values fade very fast
How about a nonlinear trust degradation?
Here's an url with most of the links
I'll certainly read this (though because of two projects that I'm getting swamped with, it'll probably be a few days until I can properly give the stuff the attention it deserves). Still, thank you very much. This looks like exactly what I like poking around with.
May we never see th
That will be all.
--------------------------------
Not all who wander, are lost.
With this credit system, how can a user who connects to the Internet through a dial-up provider and has never used an eDonkey client get better than a 6-hour wait? Many dial-up services kick a user who has been on longer than 6 hours.
I'd prefer an answer other than "just get broadband" because the next step up from dial-up may be 128 kbps IDSL for $100/mo.
Will I retire or break 10K?
But if you have a 200 entry trust list
How would one obtain a 200 entry trust list? On average, each adult human being in the world knows about 250 other adults personally in meatspace. And you assume that 80% of all your friends will use a given P2P network?
Will I retire or break 10K?
Since Gnutella is a distributed search protocol, are they going to expand it for searching for OTHER things then just files? Seems like that would be the natural evolution of things. I picture being able to search for people...maybe by a GPG key, and then being able to establish chat, video, or whatever kind of sessions with them. Now THAT would be a real gnutella2.
Isn't that something YOU want to support?
I see a hole in that. HoneyPot1 absolutely trusts RIAA1, RIAA2, RIAA3, RIAA4, RIAA5, etc. HoneyPot1 earns trust points by giving out the real thing very well, and then transfers that those points to servers that have the dud content by "trusting" them. Whats more, once HoneyPot1 gets up to its desired state of trust, it could flip itself into dud content mode as well. The attackers could repeat this process as many times as they want. A trust system dies the first time a turncoat gets a high-trust status.
From the EULA (that thing no one reads): f) High risk activities. The SOFTWARE is not designed nor intended for use in "High Risk Activities" where the failure of the SOFTWARE could lead directly to death, personal injury or severe physical, financial or environmental damage. The LICENSOR specifically disclaims any express or implied warranty of fitness for use in these activities.
There goes my plans to run my homemade nuclear reactor off the Gnutella2 Network!
The second issue is taken care of -- if HoneyPot isscrews me over, I zero his trust.
The transitive trust is a good point. A is legitimate, but A trusts B, and B is bogus, and A (deliberately or otherwise) does not update his local trust list upon B going bad. Hm.
Okay, here's a possible modification. Allow negative trust values. If I'm C, I trust A, user A trusts user B, and I consider user B a "bad guy" (negative trust), reduce C's trust of user A periodically.
May we never see th
Zeroing out HoneyPot after the fact still didn't prevent you from getting a bogus file. Expanded outward, if ten of your twelve favorite servers all turn bogus for you at the same time, you will have a rather meaningless set of trust data with trustworthy sites with low ratings and bogus sites rated high. What's more, less frequent users will not notice when a HoneyPot flips, so they'll continue to transfer a false trustworthy status to that flipped HoneyPot.
Actually, you seem to forget gtk-gnutella. It is not spyware (see the source: http://www.sf.net/projects/gtk-gnutella), and highly efficient (about 10% of CPU and 10MB of memory on my Duron800 PC).
Pretty good! (And _stable_; even the CVS version.)
I don't really agree. If the system is well designed, it's better _not_ to have a lot of different protocols, because it doesn't work that way (would you like to use five p2p clients simultaneously?).
I think G2 is such a well designed system. (Decentralized, supports different ports, among other things.)
It would be nice to have encrypted searches and file transfers. Maybe via SSL ?
amazing.
:)
This is exactly what I just proposed higher above in the comments.
Of course, since I only ever post as an AC, I'm never going to get karma (nor do I care for it).
Even so - I'm glad someone else thinks this is a good idea. (And your comment is vastly more detailed than mine)
I wonder - did you derive your idea from somewhere else? I ask, because I honestly thought this idea was not novel when I posted, but can't for the life of me remember where I'd heard it before.
It certainly has the advantage of being non-centralized.
And if you think about it - this is very much like the way people think in the real world. After all, I don't go to a centralized server to know who I trust. And I also tend to trust the people who are trusted by people I trust
But sometimes I just don't agree with some of my friends about whom they choose to trust.
This works exactly the same way.
I'd like to contribute to some of the issues that were raised in the other comments :
There are automated ways to contribute to the assignation of trust in the system.
1/ Downloading files can use the Tiger Tree algorithm to determine the correctness of the file compared to other files claiming to be the same file. This could be an automated way of downgrading trust. The more files a host shares which fail this test, the more trust that host loses. This goes hand in hand with the ability for the software client to get files from multiple sources.
2/ Secondary nodes should be able to be promoted to primary nodes in your trust tree. So if You trust A at 50% and he trusts B at 50% your transitive trust is only 25%, but that doesn't prevent you from trusting B as a primary node at 90% if your interactions with B warrant that level.
3/ I totally agree that the individual client is the only repository of the trust list. I don't really like a formalized group structure with someone being the trust-manager of the certificate. It's just too open to problems IMHO. You have to trust the certificate manager 100%.
4/ the issue of 'you scratch my back, and I'll scratch yours' is a non-issue. Trust isn't necessarily reciprocal. A can upload to B and B can deny that ever happened. who do you trust?
Non issue. You trust whoever is in your trust list. You don't care that B denies ever downloading something if you trust A. Similarly, if you have A in your trust list, and he has B in his, then you have a decent chance to trust B. B never cares enough to tell you A didn't download from him.
5/ The problem with groups is the over head. sounds like a very complicated system to formalize what is in essence, a dynamicly changing informal group structure. I guess your issue is that you don't interact with a particular node often enough to form a picture of their reliability. How is this different with a group ? If a group is only a few people in size, who may or may not be online when I'm on, how do I make it grow ? How do I choose who to "let in" to the group ? sounds like you need a centralized group leader who runs the group like a constant IRC channel.. And if you have that anyway, then there's no difference between joining his group and inspecting his trust list, because other members of the group are just as likely to be online at any given time as hosts in his trust list.
6/ 200 Entry Trust list ?
As you say, automation of trust assignation can make up for a part of this. Also, you can automate trust denial if the system can detect fake files with some sort of sharing algorithm like Tiger.
7/
Also I wonder what would happen if, instead of a mere 2 step hop of trust, we have a percentage cut-off?
For example: If you have a cut off of 25%, and A trusts B 100% and B trusts C 50%, and C trusts D 50%, then A can trust D at 25%.
But if A downgrades his trust of B to only 75%, then C gets downgraded to 37.5% and D drops off the list (18.75% is too low).
There would have to be a limit of hops for 100% trust (or some upper level, maybe 85% and above)
Of course, if you use any trust method, you have to be able to make trust adjustments so that derived trust is secondary to explicit trust.
A trusts B @50% and B trusts C @50%.
A has 25% derived trust for C, but might have 80% explicit trust.
If Z trusts A 45% and B 55%, how much does he trust C ?
The solution ?
Transitive trusts can be promoted to primary trust values. So A has a trust value for B of 50% and B trusts C 50%, A has a transitive trust of C of 25%, but can have a primary trust of C of 100% or 0% or whatever, which overrides any derived values.
Example :
Just because my best friend Johnny has a girlfriend doesn't mean I _have_ to like her
Sure I might start out with a predispostion that way, because I trust his judgement, but after a few interactions I realize she's a complete bitch.
I manually downgrade that node from a transitive trustworthy status to a primary untrusted status.
No problems.
* This is complicated. Has to do with interrupts. Thus, I am :-P
* scared witless. Therefore I refuse to write this function.
-- From the maclinux patch
- this post brought to you by the Automated Last Post Generator...