While automatic seeding is *technically* not in equilibrium, you are correct that my argument would be rather poor if that were the only thing that differs between the current client implementations and the ideal which would always act in the downloaders' best interest.
There are many other ways in which the BT clients are "unfair." (again, I stress that this is a technical term) I can't go into all of them here, but one of the biggest that I can explain, since you do obviously have some understanding of this subject, is the problem of optimistic unchoking.
If you don't know what that term means, then Cohen's original economics paper gives a good explanation. Azureus, the best client I know of and the one I use, though there are still problems with it, will even let you see which peers you are currently optimistically unchoking.
Anyway, the problem is that EVERYONE does this, ALL THE TIME. I assume that you already know why. But, now assume that one person modifies their client so that it doesn't. He will still be optimistically unchoked by everyone he is connected to, and can therefore determine the upload rates of his peers, which is the whole reason why the clients do this. By disabling optimistic unchoking, the peer gains a slight advantage in that he can always be uploading to the best peers he knows of, instead of risking bandwidth to test out peers. We therefore conclude that in the current environment of everyone optimistically unchoking, it is in each individual's best interest to completely disable optimistic unchoking.
Of course, this leads to a problem. If all users do this, as we should expect them to, then the environment changes and now NO ONE optimistically unchokes. In this scenario, the best thing to do is once again risk some bandwidth to test peers by optimistically unchoking. Therefore, it becomes in everyone's best interest to optimistically unchoke, and we should assume that they will do so (given the fact that once a client is written that allows people to disable/enable OU, people won't have to know how to modify the source and recompile). This creates the previous environment, where everyone is optimistically unchoking. You would think, therefore, that people would be constantly switching OU on and off. But there is an equilibrium strategy: optimistically unchoke only a certain percentage of the time. Calculating what this percentage is would be difficult, as it would rely on many variables including the number of peers you are connected to, how often and how recently you have OU'ed them, your current download rate, the percentage of OU'ed peers that become permanent, and so on. What the clients should do is EITHER allow the user to choose a value for each of the variables I mentioned as well as a formula for how those values are to be combined, OR allow a plugin that will decide when to OU that the user can write in a high level language, OR both.
Hopefully, you can see now that my last year has not been wasted.
>Even in your hypothetical economically ideal system, the system could benefit from people being tricked into giving more than they intended.
The system benefits, yes. And I'm sure that many people would choose to seed if they can spare the bandwidth, even if they get nothing out of it. The problem though is that some clients will allocate bandwidth for seeding even when there's another download in progress. Also, people might be mindful of the amount of data they're uploading. Maybe someone is on an ethernet LAN, and the seeding causes contention with other users. My point is that since seeding is usually of no benefit to the seeder, and since seeding can in some cases be detrimental, it shouldn't be forced on people by moralistic clients (and client developers).
>Your pet peeve with the BitTorrent protocol is that seeds always upload as fast as possible, when that isn't always necessary to get the file distributed. Well I think you have the objective of the BitTorrent protocol wrong.
You are correct in that we disagree on the primary use or "objective" of BT. Most people see BT as a (illegal) file sharing tool for an informal cooperative group, and that is why they get angry when someone doesn't seed. They say, "You're getting something for nothing here, the least you could do is seed!" Instead, I take the view of the researcher comparing this peer-to-peer architecture to the standard client-server architecture. There exists an individual or group that wishes to distribute information to a large number of people. The distributors care only about the health of the swarm. They want to spread their information as wide as possible. And they'd like to do it as cheap as possible. Then there are the downloaders, who just want to download the data as fast as possible, using only as much of their possibly precious upload bandwidth as possible. A good example of this situation would be a movie trailer. Note that I have nothing against illegal file sharing. To me it doesn't matter what the bits represent, only the manner in which they are distributed.
The behavior of the clients should reflect the goals of these "rivals." (economic term) The clients should not act in a way that their users would not want them to, because that creates an "unfair" (networking term) situation: those people knowledgeable enough to modify their clients could take advantage of the rest.
Using seeding and leaching algorithms that are in economically equilibrium is the only way to eliminate the "unfairness" described above.
I advocate maximizing the average download rate, but only with no unfairness. You seem to advocate maximizing the average download rate at any cost. This is actually not a bad thing, and I will not criticise you if that is the case. TCP congestion control has similar fairness problems, and there are two well-established camps: those who believe fairness is more important than speed, and those who believe speed is more important than fairness. While I am in the former camp, I do respect the opinions of the latter, so long as they know why they believe what they believe.
>Furthermore, even if the objective of seeders was to conserve total bandwidth
I believe seeders are really only concerned with distributing whatever data it is they are trying to distribute. They care about the health of the swarm, and will use upload bandwith if it will help the swarm. But if seeding will not help significantly, then it is better for them to do something else with the bandwidth, like seed for a more needy swarm.
>A seed on a symmetric connection would only use half of its upload at maximum
I said 2 bits for every 1 bit, but that could be changed to maybe 11 for 10, just enough to encourage peers to trade with each other as much as possible before asking for assistance from seeds. And while the maximum bandwidth would be slightly less, it would be used much more effectively, if a client is seeding hundreds of swarms.
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has cancelled a download. 2) Nobody has falsified their amount downloaded. 3) No data is ever discarded and there are never any hash fails. 4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
I can't believe this... my post gets "Flamebait" and this gets +5?
>Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded.
Guess you've never heard of lost packets.
>And hash fails are counted as downloads by the client, so thats not a factor.
"CHANGE: Core | Download totals don't include hash fails and discards and aren't included in share-ratio calculation [Parg]"
From: http://cvs.sourceforge.net/viewcvs.py/*checkout*/a zureus/azureus2/ChangeLog.txt?rev=HEAD
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has canceled a download.
2) Nobody has falsified their amount downloaded.
3) No data is ever discarded and there are never any hash fails.
4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
>The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market.
Several people have responded to me stating that BT actually is like capitalism, and that I should go read Bram's economic paper.
I HAVE read that paper, and in it he states that one of the big reasons for the success of the protocol is that people leave their download windows open after they're done downloading. This ties up the client's upload pipe needlessly, and the only reason that the rational person would allow this is that they've walked away from their computer and haven't altered the source code to prevent seeding. Also, Bram's decision to use recent download rates instead of recent amount downloaded prevents bit-for-bit trading (necessary for the free-market idea), which instead of creating a paradigm of trade creates instead only a paradigm of expected reciprocity, and inexact reciprocity at that.
Someone stated that BT is based on game theory principles and that I should learn game theory. Actually, everything that I'm saying is based on game theory. Bram Cohen and the other client developers seem to only have a vague, "you scratch my back and i'll scratch yours" understanding of it. The reason I say this is because of comments that they've made elsewhere. A while back an article was posted on slashdot about Microsoft making some kind of BT-like protocol, and Bram bashed them for advocating bit-for-bit reciprocity. As much as I hate M$, I have to admit they were right that time. There are other comments that Bram and others have made that do not hold up to mathematical analysis, but I'm not going to bother citing them here.
>Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.
Actually, it should be aimed at both. The client developers are still using what I described above as "expected reciprocity." Also, the Azureus dev team has recently implemented a feature called "private torrent." I won't bother to descibe what this does here (you can find out for yourself) but suffice it to say there is no reason why any rational (keyword here is rational, not moralistic) person would enable this as it only limits their available connections. Ignoring protocol overhead, more connections is always better because it is more robust, allows for a more accurate random sample of the true value (in the entire swarm) of piece availability, and increases the effective (what your client can see) piece availability.
Also, I've talked with the Azureus dev team and confirmed (they even agreed with me) that they don't know anything about game theory.
>Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed
If every client had a "seed?" checkbox that was disabled by default, and everyone were rational, only those who are genuinely interested in distributing the information would seed. This is exactly the way it should be. The way it is now, users are tricked into seeding by moralistic do-it-for-the-good-of-the-swarm clients that require explicit user actions to prevent seeding. People don't choose to seed, they simply fail to choose not to seed.
As for the 2 to 1 ratio on seeds, the whole idea of BT is to make data distribution scalable and reduce the bandwidth needed by the seed (I say "seed" because there really needs to be only one, no matter how large the swarm, if this idea of mine were to be implemented). The idea is NOT to maximize the average download rate of the downloaders. Indeed, if my suggestions were followed, the average download rate would decrease because of asymmetric line speeds. But, uploading by the server/seed would be minimized, and much more importantly, the "game" (game theory terminology here) would be in a state of "economic equilibrium" also known as a "Nash equilibrium." What this means in English is that it is no longer possible to modify a client's behavior to get better results. Experts won't be a
First of all, I don't use private torrent sites, so don't think I'm a cheater.
However, I can easily get 0.2 to 0.3 on most torrents when I'm done downloading. (I try to get a share ratio as low as possible, and not because I'm an asshole, read my post outside this thread for an explanation) And the thing is, each individual peer has no way of knowing that I'm not uploading lots of data to someone else, so just because my ratio to a given peer is low, does not necessarily mean my overall ratio is low. So, my false upload value reported to the server is not verifiably false, even if you have several "spy" peers that are connected to me and are not getting as much as they upload.
This idea is actually similar to the way plausible deniability works in the current version of Freenet. It is impossible to prove, no matter how many connections you establish to a member, that that member is not actually connected to another member that is requesting the data.
I suggest you take out a book on game theory and try cheating. You'll realize that if everyone were to act like an asshole (and not give away data unless they get the most they can get in return), the system will reach an equilibrium in which, for large swarms, NO seeding is needed.
Excellent example of the stupidity that pervades the BT community. IMNSHO, anyone who develops a BT client should have taken a course or read a book on game theory. You CAN'T understand the economic incentives at work here without a firm grasp of the subject.
You're only detecting the small fraction of the cheaters that don't realize they're being obvious. If you look at my post above, I explain how it is very easy to trick trackers. You just use a random number generator to generate 1-2x the amount you've downloaded. It'll look totally legit.
I've been studying BT for over a year now, and this problem is very obvious and well-known. So, anyone who claims that they shouldn't have posted this because it's going to kill BT is wrong. They shouldn't have posted it because it's obvious to anyone who reads the BT protocol. You can just modify the source code and send a random real from zero to one, plus one, times however much you've downloaded and you've got a share ration between 1 and 2. Simple.
The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most: instead of forcing people to be cooperative by enforcing seeding requirements either in the client or at the trackers, simply recognize that swarming creates an inherently competetive environment, as everyone is really only concerned about their download and SHOULD only be concerned about their download, and let people use the most unscrupulous tactics they can think of to game the system. The way it will play out is that people will end up with a share ratio close to 1. The swarms become like little free markets: if you have a valuable piece, you can agree to trade for a lot of data. If someone breaks their agreement, you ban their IP address for a while. If you're willing to upload twice as much as you request from others, EVERYONE will want to trade with you.
If you do the math and economic analysis, everyone ends up trading on a 1 for 1 ratio, seeds only have to upload when there's very few peers (they simply require 2 bits from you for every bit they upload, that way people will only rely on seeds if they can't get a piece any other way, specifically, if the availability of the piece is zero), and no one other than the individual or group publishing the data needs to seed. BT was never meant (whether Bram Cohen realizes this or not) to shift the responsibility of serving from the publisher to the clients, it was meant to reduce the amount of bandwidth needed to publish data.
The current system is like socialism. It needs to become more like capitalism, and I'm not even a laissez-faire capitalist! Why no one realizes this is beyond me.
Slashdot Mirror
While automatic seeding is *technically* not in equilibrium, you are correct that my argument would be rather poor if that were the only thing that differs between the current client implementations and the ideal which would always act in the downloaders' best interest.
There are many other ways in which the BT clients are "unfair." (again, I stress that this is a technical term) I can't go into all of them here, but one of the biggest that I can explain, since you do obviously have some understanding of this subject, is the problem of optimistic unchoking.
If you don't know what that term means, then Cohen's original economics paper gives a good explanation. Azureus, the best client I know of and the one I use, though there are still problems with it, will even let you see which peers you are currently optimistically unchoking.
Anyway, the problem is that EVERYONE does this, ALL THE TIME. I assume that you already know why. But, now assume that one person modifies their client so that it doesn't. He will still be optimistically unchoked by everyone he is connected to, and can therefore determine the upload rates of his peers, which is the whole reason why the clients do this. By disabling optimistic unchoking, the peer gains a slight advantage in that he can always be uploading to the best peers he knows of, instead of risking bandwidth to test out peers. We therefore conclude that in the current environment of everyone optimistically unchoking, it is in each individual's best interest to completely disable optimistic unchoking.
Of course, this leads to a problem. If all users do this, as we should expect them to, then the environment changes and now NO ONE optimistically unchokes. In this scenario, the best thing to do is once again risk some bandwidth to test peers by optimistically unchoking. Therefore, it becomes in everyone's best interest to optimistically unchoke, and we should assume that they will do so (given the fact that once a client is written that allows people to disable/enable OU, people won't have to know how to modify the source and recompile). This creates the previous environment, where everyone is optimistically unchoking. You would think, therefore, that people would be constantly switching OU on and off. But there is an equilibrium strategy: optimistically unchoke only a certain percentage of the time. Calculating what this percentage is would be difficult, as it would rely on many variables including the number of peers you are connected to, how often and how recently you have OU'ed them, your current download rate, the percentage of OU'ed peers that become permanent, and so on. What the clients should do is EITHER allow the user to choose a value for each of the variables I mentioned as well as a formula for how those values are to be combined, OR allow a plugin that will decide when to OU that the user can write in a high level language, OR both.
Hopefully, you can see now that my last year has not been wasted.
>Even in your hypothetical economically ideal system, the system could benefit from people being tricked into giving more than they intended.
The system benefits, yes. And I'm sure that many people would choose to seed if they can spare the bandwidth, even if they get nothing out of it. The problem though is that some clients will allocate bandwidth for seeding even when there's another download in progress. Also, people might be mindful of the amount of data they're uploading. Maybe someone is on an ethernet LAN, and the seeding causes contention with other users. My point is that since seeding is usually of no benefit to the seeder, and since seeding can in some cases be detrimental, it shouldn't be forced on people by moralistic clients (and client developers).
>Your pet peeve with the BitTorrent protocol is that seeds always upload as fast as possible, when that isn't always necessary to get the file distributed. Well I think you have the objective of the BitTorrent protocol wrong.
You are correct in that we disagree on the primary use or "objective" of BT. Most people see BT as a (illegal) file sharing tool for an informal cooperative group, and that is why they get angry when someone doesn't seed. They say, "You're getting something for nothing here, the least you could do is seed!" Instead, I take the view of the researcher comparing this peer-to-peer architecture to the standard client-server architecture. There exists an individual or group that wishes to distribute information to a large number of people. The distributors care only about the health of the swarm. They want to spread their information as wide as possible. And they'd like to do it as cheap as possible. Then there are the downloaders, who just want to download the data as fast as possible, using only as much of their possibly precious upload bandwidth as possible. A good example of this situation would be a movie trailer. Note that I have nothing against illegal file sharing. To me it doesn't matter what the bits represent, only the manner in which they are distributed.
The behavior of the clients should reflect the goals of these "rivals." (economic term) The clients should not act in a way that their users would not want them to, because that creates an "unfair" (networking term) situation: those people knowledgeable enough to modify their clients could take advantage of the rest.
Using seeding and leaching algorithms that are in economically equilibrium is the only way to eliminate the "unfairness" described above.
I advocate maximizing the average download rate, but only with no unfairness. You seem to advocate maximizing the average download rate at any cost. This is actually not a bad thing, and I will not criticise you if that is the case. TCP congestion control has similar fairness problems, and there are two well-established camps: those who believe fairness is more important than speed, and those who believe speed is more important than fairness. While I am in the former camp, I do respect the opinions of the latter, so long as they know why they believe what they believe.
>Furthermore, even if the objective of seeders was to conserve total bandwidth
I believe seeders are really only concerned with distributing whatever data it is they are trying to distribute. They care about the health of the swarm, and will use upload bandwith if it will help the swarm. But if seeding will not help significantly, then it is better for them to do something else with the bandwidth, like seed for a more needy swarm.
>A seed on a symmetric connection would only use half of its upload at maximum
I said 2 bits for every 1 bit, but that could be changed to maybe 11 for 10, just enough to encourage peers to trade with each other as much as possible before asking for assistance from seeds. And while the maximum bandwidth would be slightly less, it would be used much more effectively, if a client is seeding hundreds of swarms.
>downloading from swarms with mostly seeds wo
I can't believe this... my post gets "Flamebait" and this gets +5?
a zureus/azureus2/ChangeLog.txt?rev=HEAD
>Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded.
Guess you've never heard of lost packets.
>And hash fails are counted as downloads by the client, so thats not a factor.
"Download totals don't include hash fails and discards and aren't included in share-ratio calculation"
From:
http://cvs.sourceforge.net/viewcvs.py/*checkout*/
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has cancelled a download.
2) Nobody has falsified their amount downloaded.
3) No data is ever discarded and there are never any hash fails.
4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
I can't believe this... my post gets "Flamebait" and this gets +5? >Globally, across an entire torrent, the amount of data uploaded can't be greater than the amount downloaded. Guess you've never heard of lost packets. >And hash fails are counted as downloads by the client, so thats not a factor. "CHANGE: Core | Download totals don't include hash fails and discards and aren't included in share-ratio calculation [Parg]" From: http://cvs.sourceforge.net/viewcvs.py/*checkout*/a zureus/azureus2/ChangeLog.txt?rev=HEAD
>If the torrent admin looks through a torrent and sees Joe Cheater claiming to have uploaded 3.6GB, and it just so happens that the amount uploaded is 3.6GB more than that downloaded...its not hard to work out who's spoofing their stats.
This assumes ALL of the following:
1) Nobody has canceled a download.
2) Nobody has falsified their amount downloaded.
3) No data is ever discarded and there are never any hash fails.
4) No one controls more than one client.
>The short answer is -- you can fudge your stats all you want. But unless you can find a way to fudge someone elses stats to minus the discrepancy, you'll get caught. And rightly so.
Because it's SOOO hard to get another IP address.
Goddamn idiots! Learn something about computer networking before you post here, PLEASE!
>The design of the BitTorrent protocol is and always has been grounded in the economic principles of the free market.
Several people have responded to me stating that BT actually is like capitalism, and that I should go read Bram's economic paper.
I HAVE read that paper, and in it he states that one of the big reasons for the success of the protocol is that people leave their download windows open after they're done downloading. This ties up the client's upload pipe needlessly, and the only reason that the rational person would allow this is that they've walked away from their computer and haven't altered the source code to prevent seeding. Also, Bram's decision to use recent download rates instead of recent amount downloaded prevents bit-for-bit trading (necessary for the free-market idea), which instead of creating a paradigm of trade creates instead only a paradigm of expected reciprocity, and inexact reciprocity at that.
Someone stated that BT is based on game theory principles and that I should learn game theory. Actually, everything that I'm saying is based on game theory. Bram Cohen and the other client developers seem to only have a vague, "you scratch my back and i'll scratch yours" understanding of it. The reason I say this is because of comments that they've made elsewhere. A while back an article was posted on slashdot about Microsoft making some kind of BT-like protocol, and Bram bashed them for advocating bit-for-bit reciprocity. As much as I hate M$, I have to admit they were right that time. There are other comments that Bram and others have made that do not hold up to mathematical analysis, but I'm not going to bother citing them here.
>Your entire rant is misguided and off-base; it should be aimed at the writers and users of ratio trackers, not the clients.
Actually, it should be aimed at both. The client developers are still using what I described above as "expected reciprocity." Also, the Azureus dev team has recently implemented a feature called "private torrent." I won't bother to descibe what this does here (you can find out for yourself) but suffice it to say there is no reason why any rational (keyword here is rational, not moralistic) person would enable this as it only limits their available connections. Ignoring protocol overhead, more connections is always better because it is more robust, allows for a more accurate random sample of the true value (in the entire swarm) of piece availability, and increases the effective (what your client can see) piece availability.
Also, I've talked with the Azureus dev team and confirmed (they even agreed with me) that they don't know anything about game theory.
>Your suggestion requiring uploads to seeds is stupid, because people would be even *less* likely to seed
If every client had a "seed?" checkbox that was disabled by default, and everyone were rational, only those who are genuinely interested in distributing the information would seed. This is exactly the way it should be. The way it is now, users are tricked into seeding by moralistic do-it-for-the-good-of-the-swarm clients that require explicit user actions to prevent seeding. People don't choose to seed, they simply fail to choose not to seed.
As for the 2 to 1 ratio on seeds, the whole idea of BT is to make data distribution scalable and reduce the bandwidth needed by the seed (I say "seed" because there really needs to be only one, no matter how large the swarm, if this idea of mine were to be implemented). The idea is NOT to maximize the average download rate of the downloaders. Indeed, if my suggestions were followed, the average download rate would decrease because of asymmetric line speeds. But, uploading by the server/seed would be minimized, and much more importantly, the "game" (game theory terminology here) would be in a state of "economic equilibrium" also known as a "Nash equilibrium." What this means in English is that it is no longer possible to modify a client's behavior to get better results. Experts won't be a
First of all, I don't use private torrent sites, so don't think I'm a cheater.
However, I can easily get 0.2 to 0.3 on most torrents when I'm done downloading. (I try to get a share ratio as low as possible, and not because I'm an asshole, read my post outside this thread for an explanation) And the thing is, each individual peer has no way of knowing that I'm not uploading lots of data to someone else, so just because my ratio to a given peer is low, does not necessarily mean my overall ratio is low. So, my false upload value reported to the server is not verifiably false, even if you have several "spy" peers that are connected to me and are not getting as much as they upload.
This idea is actually similar to the way plausible deniability works in the current version of Freenet. It is impossible to prove, no matter how many connections you establish to a member, that that member is not actually connected to another member that is requesting the data.
I suggest you take out a book on game theory and try cheating. You'll realize that if everyone were to act like an asshole (and not give away data unless they get the most they can get in return), the system will reach an equilibrium in which, for large swarms, NO seeding is needed.
Excellent example of the stupidity that pervades the BT community. IMNSHO, anyone who develops a BT client should have taken a course or read a book on game theory. You CAN'T understand the economic incentives at work here without a firm grasp of the subject.
You're only detecting the small fraction of the cheaters that don't realize they're being obvious. If you look at my post above, I explain how it is very easy to trick trackers. You just use a random number generator to generate 1-2x the amount you've downloaded. It'll look totally legit.
I've been studying BT for over a year now, and this problem is very obvious and well-known. So, anyone who claims that they shouldn't have posted this because it's going to kill BT is wrong. They shouldn't have posted it because it's obvious to anyone who reads the BT protocol. You can just modify the source code and send a random real from zero to one, plus one, times however much you've downloaded and you've got a share ration between 1 and 2. Simple.
The simplest and best solution to this problem is the one that idiots (especially BT client developers like Bram Cohen and the Azureus dev team) tend to dislike the most: instead of forcing people to be cooperative by enforcing seeding requirements either in the client or at the trackers, simply recognize that swarming creates an inherently competetive environment, as everyone is really only concerned about their download and SHOULD only be concerned about their download, and let people use the most unscrupulous tactics they can think of to game the system. The way it will play out is that people will end up with a share ratio close to 1. The swarms become like little free markets: if you have a valuable piece, you can agree to trade for a lot of data. If someone breaks their agreement, you ban their IP address for a while. If you're willing to upload twice as much as you request from others, EVERYONE will want to trade with you.
If you do the math and economic analysis, everyone ends up trading on a 1 for 1 ratio, seeds only have to upload when there's very few peers (they simply require 2 bits from you for every bit they upload, that way people will only rely on seeds if they can't get a piece any other way, specifically, if the availability of the piece is zero), and no one other than the individual or group publishing the data needs to seed. BT was never meant (whether Bram Cohen realizes this or not) to shift the responsibility of serving from the publisher to the clients, it was meant to reduce the amount of bandwidth needed to publish data.
The current system is like socialism. It needs to become more like capitalism, and I'm not even a laissez-faire capitalist! Why no one realizes this is beyond me.