Time to END the slot-faking

Scope · Post by **Scope** » 2004-10-24 08:34

This has been discussed before, and nothing has been done to it. The way I see it the only way to fix this problem is this :
First action to take against slot-faking is dedicated slots. Slots / Hub. If you have 1 slot open and connected to 2 hubs, each hub should have one dedicated slot which means a total of 2 open slots. This way the hubs can control the dedicated slots within the hub. Now we can add commands to the extended protocol like : $uploads and $downloads.
$uploads will tell which one(s) are downloding from the client in the current hub.
$downloads will tell all your downloads in the current hub.
If a hubowner wants to check someone simply just send the $uploads command and then check if the user(s) are really downloading from the user with the $downloads command.

Post by **ullner** » 2004-10-24 08:40

And how are you going to tell if the user isn't sending out false commands?

Scope · Post by **Scope** » 2004-10-24 08:43

ullner wrote:And how are you going to tell if the user isn't sending out false commands?

Please define false commands.

Todi · Post by **Todi** » 2004-10-24 08:43

Thanks for the effort, but i don't really feel comfortable with the evil operators knowing exactly who i upload to and download from.

Scope · Post by **Scope** » 2004-10-24 08:48

Todi wrote:Thanks for the effort, but i don't really feel comfortable with the evil operators knowing exactly who i upload to and download from.

Well add a privacy setting "Allow operators to view my uploads/downloads"

If you dont allow it, you might not be welcome in some hubs, but a good choice for ppl tired of slot-fakers.

And another thing about privacy, search-spy !?

cologic · Post by **cologic** » 2004-10-24 08:48

First thought: How does a hub perform that verification check if I claim I'm uploading only to those from other hubs?

Edit: oh, hey, you posted simultaneously.

LOL.

Think about your search spy complaint, and juxtapose it with your proposal. Repeat until you see the hypocrisy.

Scope · Post by **Scope** » 2004-10-24 08:53

cologic wrote:First thought: How does a hub perform that verification check if I claim I'm uploading only to those from other hubs?

Edit: oh, hey, you posted simultaneously.

LOL.

Think about your search spy complaint, and juxtapose it with your proposal. Repeat until you see the hypocrisy.

Read my post again, then you can remove that post that only make you look stupid or ignorant

cologic · Post by **cologic** » 2004-10-24 08:58

What, your 'allow ops to spy on me' (an accurate characterization moreso than 'search spy', which only displays data necessary to the operation of the network anyway) setting?

Well, if hubs don't require it, it's, well, worthless (why otherwise volunteer?). If hubs do require it, it's worthless (presents a facade of choice).

Finally: respond to my (primary) question about multiple hubs? The search spy's tangential.

Todi · Post by **Todi** » 2004-10-24 09:05

Mm.. it would be interesting to know how we're gonna display the number of slots in the searchresults, since DC++ still has problems deciding where a search is coming from.

Scope · Post by **Scope** » 2004-10-24 09:06

cologic wrote:What, your 'allow ops to spy on me' (an accurate characterization moreso than 'search spy', which only displays data necessary to the operation of the network anyway) setting?

Well, if hubs don't require it, it's, well, worthless (why otherwise volunteer?). If hubs do require it, it's worthless (presents a facade of choice).

Finally: respond to my (primary) question about multiple hubs? The search spy's tangential.

I did not complain about search spy, we were discussing privacy and I think that ppl knowing what I am searchin for like "xxx cumshot ricky lake" is more invading on my privacy than letting ops know which USERS i am downloading and uploading from/to. They dont get the information WHAT you are downloading/uploading.

And the answer to your STUPID IGNORANT question about multiple hubs : DEDICATED SLOTS.

Now please stop posting here.

Post by **ullner** » 2004-10-24 09:07

There is no privacy issue with the Search Spy (not atleast in DC++) since you can't see who is performing the search.

Todi · Post by **Todi** » 2004-10-24 09:07

Best Way Not To Get Your Suggested Feature Implemented: Get pissed off and angry when one of the DC developers point out flaws in your clever plan.

cologic · Post by **cologic** » 2004-10-24 09:14

As Todi points out, the DC protocol prevents dedicated slots. See one of the multiple shares/hubs threads for why. Therefore, I had hoped it wasn't critical to your idea. Oh well.

Now, pretend that problem can be solved (a new protocol would do it; ADC for example), and a trivial modification: a pair/triplet/quadruplet of clients, which cooperates among themselves to present a unified front. Two clients is easy to set up even for an individual.

Regarding search spy: perhaps. Broadcast searches form the basis for DC, though. Hard to change that, and preventing one-click display in the stock client would accomplish little.

Scope · Post by **Scope** » 2004-10-24 09:15

Todi wrote:Best Way Not To Get Your Suggested Feature Implemented: Get pissed off and angry when one of the DC developers point out flaws in your clever plan.

Being pissed off at cologic for posting stupid remarks about my suggestion is not called for?
He obviously didnt read my post about dedicated slots and wanted to be a wiseass "uh huh what about mutiple hubs..bla bla bla"

Im up for a serious discussion

Scope · Post by **Scope** » 2004-10-24 09:21

Todi wrote:Mm.. it would be interesting to know how we're gonna display the number of slots in the searchresults, since DC++ still has problems deciding where a search is coming from.

Client checks the user searching which hub he's connected to, report that hubs dedicated slot count, if user is connected to hubs as the searcher is, report the one that has the most free slots.

Scope · Post by **Scope** » 2004-10-24 09:37

cologic wrote:As Todi points out, the DC protocol prevents dedicated slots. See one of the multiple shares/hubs threads for why. Therefore, I had hoped it wasn't critical to your idea. Oh well.

Now, pretend that problem can be solved (a new protocol would do it; ADC for example), and a trivial modification: a pair/triplet/quadruplet of clients, which cooperates among themselves to present a unified front. Two clients is easy to set up even for an individual.

Regarding search spy: perhaps. Broadcast searches form the basis for DC, though. Hard to change that, and preventing one-click display in the stock client would accomplish little.

Drop the search spy it was a comparison of pricacy and it wasnt meant for you, BUT HEY FEEL FREE TO ANSWER OTHER PPL'S POSTS! Since you seem to love typing. The protocol does not have anything to do with the dedicated slot part except reporting slot count when searching. Which can be handled by the client knowing the user searching and the hub(s) you and him/her are connected to.

Oh yeah its really easy to create clients reporting downloading/uploading from/to eachother. Keeping track of their names (which definately includes them communicating with eachother) and not report them downloading when they get disconnected, and only report them downloading when they connect to the hub. Oh yeah its piece of cake for an average programmer to make this shit.

ivulfusbar · Post by **ivulfusbar** » 2004-10-24 10:21

Back to your first post in this thread. Nothing has been done because your idea is plain stupid. ;))

Why should we work on something useless and stupid?

Again as cologic said. The current protocol do not support any user-->which hub he/she connected from making the dedication only guesses. Such guesses will be rejected for forever.

Todi · Post by **Todi** » 2004-10-24 10:30

Edit: not qualified enough

Post by **ullner** » 2004-10-24 10:52

If it's so simple to code, I expect a patch from you being sent to arnetheduck.

Scope · Post by **Scope** » 2004-10-24 13:52

If 2 different users have the same name on 2 different hubs you have to guess, yes. Now if we have this scenario the client answering the search knows this and can take actions before guessing. The client can in this case chose the hub which has the most free slots. So IF that user on that hub isnt the same user which is searching, then let the searching client BELIEVE the use has free slots (even if its not on the hub he's on). When the client tries to download it will reveal the correct slot count. This scenario is VERY seldom and can be fixed later on or now by giving each client a unique guid at each startup which can be collected by a extended protocol hello command for instance. Which can be sent when this scenario appears. And if the clients doesnt support this command you can either report the slot count on the hub with most free slots, or even not reply on the search bacuse the client doesnt support the hello command. Remember that this ONLY happens in this rare scenario, and will never happen if everyone upgrades in the future. There are many different ways of doing this, and its not a stupid idea! The absolutely most simple way of faking is reporting no slots available. It can be done by rewriting ONE line in the DC++ source code! If this is implemented it will be VERY VERY hard to fake no slots available.

cologic · Post by **cologic** » 2004-10-24 14:25

You've just outlined various DC shortcomings regarding multiple hub support and workarounds (well, partial ones: user-GUIDs aren't sufficient, because the same pair of users could both be on multiple hubs, and per-user-GUIDs don't disambiguate connections).

The changes you suggest aren't likely to get into DC any time soon; much more credible causes have required them (see, again, differing shares across hubs) and haven't induced their implementation. I would suggest looking to ADC as a potential baseline. It handles multiple hubs correctly, without guesswork, and is more open to modification.

This leaves the technical issue of cooperating cliques (which your response rather quickly dismissed; easy or not to initially program, it only has to happen once for many to use it) and the social issue that rather than solving anything, you've merely moved the problem from trusting that a user's not lying about his free slots to that the downloaders confirm uploaders' activity, potentially against their self-interest.

Post by **GargoyleMT** » 2004-10-24 15:22

Scope wrote:Being pissed off at cologic for posting stupid remarks about my suggestion is not called for?

Yes. They're not stupid. You're expected to be able to defend your feature suggestion (like your Thesis [hihihi]) against criticism without resorting to name-calling.

ivulfusbar · Post by **ivulfusbar** » 2004-10-24 16:28

Scope:

Ok lets try to explain this. I have no idea why you talk about searches but hey if you need it explained i can atleast try. First, if you are an active user dc++ will always guess on every incomming search without knowing. This guess is determined on the nickname and or host:port used in search-replies. This is ofcourse not enough information to accuratly determine the correct answer. (Consider for example multihome-hubs or hubs that use different ports... blah blah...)

In the CTM-handshake its pure guessing. On both sides. I can easily fake my nickname when downloading from you. Then you will not report "me" as uploader. et...c.. blah blah.. same in other direction ofcourse...

Infact, in my oppinion your suggestion is way worse than the current state, because with your system i can send wrong information. And then trigger people to act on this information.

its-way-way-worse-ly'ers

Scope · Post by **Scope** » 2004-10-25 20:21

ivulfusbar wrote:Scope:

Ok lets try to explain this. I have no idea why you talk about searches but hey if you need it explained i can atleast try. First, if you are an active user dc++ will always guess on every incomming search without knowing. This guess is determined on the nickname and or host:port used in search-replies. This is ofcourse not enough information to accuratly determine the correct answer. (Consider for example multihome-hubs or hubs that use different ports... blah blah...)

In the CTM-handshake its pure guessing. On both sides. I can easily fake my nickname when downloading from you. Then you will not report "me" as uploader. et...c.. blah blah.. same in other direction ofcourse...

Infact, in my oppinion your suggestion is way worse than the current state, because with your system i can send wrong information. And then trigger people to act on this information.

its-way-way-worse-ly'ers

This would be a TOOL for operators to find slot-fakers. Not something to be used in scripts. Of course you can make a client that doesnt report downloads, you can make a client that upload fake files filled with crap, fake no slots available, not answer searches etc. etc. If an operator finds something fishy, he can check all uploaders/downloaders in that chain and probably in most cases rule out the guilty. Downloaders/Uploaders should be reported with both ip and username, this way the operator can see if you fake your nickname. AND its alot of work for someone to modify a client to fake this, connect to someone to get their ip and use their username, and by the time you get the users ip he might have disconnected or whatever. Faking uploads is useless since other ppl has to verify you. And if SOMEONE doesnt verify you beacuse of a modified client, SOMEONE ELSE will, which will make the operator to check that person.

Twink · Post by **Twink** » 2004-10-25 23:13

would it not just be easier to write a bot that changes it name occasionally and is not an op that tries downloading a small file off a user every now and then taking note on slots taken?. Yes the idea proposed at the start of this thread would be alot quicker but as pointed out it would not work with the current protocol and still can be circumvented, not as easily as the current system by why replace the current system with something broken?

If my client says I'm uploading to you and your client says i'm not, who is lying?

ivulfusbar · Post by **ivulfusbar** » 2004-10-26 01:09

Scope:

The average OP is extremly stupid and would not know what todo if he user1 says somethings and user2 says another thing. Then an OP does the only thing he has good at, kicks both for not understanding. ;))

And it WILL be used automaticly regardles if you think it should be or not. Thats what history chown us. Look at all the CDMs. Do you think people will not use it automaticly?

Scope · Post by **Scope** » 2004-10-26 11:45

Twink wrote:would it not just be easier to write a bot that changes it name occasionally and is not an op that tries downloading a small file off a user every now and then taking note on slots taken?. Yes the idea proposed at the start of this thread would be alot quicker but as pointed out it would not work with the current protocol and still can be circumvented, not as easily as the current system by why replace the current system with something broken?

First off, uploads cant be faked unless you use multiple clients that is which nobody will. You can make a modified client not reporting downloads. But that wont help you fake no slots available. So whats the gain? Who wants to use that and risk being kicked/banned for not reporting downloads?

Twink wrote: If my client says I'm uploading to you and your client says i'm not, who is lying?

Since you gain more from faking uploads, you will assume that you are the guilty one. If you have more than 1 slot the operator can check the other upload as well, and if both doesnt report you, what are the odds of two random users using a modified client not reporting downloads? So that will result in a ban. Now if you only have 1 slot. You need to verify the other user as well. First check HIS uploads/share etc. I doubt that someone would use a client that ONLY reports no downloads.

I mean clients not reporting downloads.....lol, who wants to do that? You want the ppl you download from kicked so cant download the things you want? And risking getting kicked/banned yourself ?

Well as I said it would not be 100% secure, but it would be a great tool for operators.

cologic · Post by **cologic** » 2004-10-26 12:10

I would use such a client, if only for the amusement value. (This is not to suggest that more self-interested rationales don't exist, but merely that it's unimportant whether they do.)

Scope · Post by **Scope** » 2004-10-26 13:50

cologic wrote:I would use such a client, if only for the amusement value. (This is not to suggest that more self-interested rationales don't exist, but merely that it's unimportant whether they do.)

Omg you would use one? Well it doesnt surprise me at all! Stupid ppl doesnt always understand what is best for them, but eventually they do!

2 slots minimum / hub would be sufficient to rule out ppl who doesnt report downloads. Which would be you and your stupid friends

Scope · Post by **Scope** » 2004-10-26 14:02

ivulfusbar wrote:Scope:

The average OP is extremly stupid and would not know what todo if he user1 says somethings and user2 says another thing. Then an OP does the only thing he has good at, kicks both for not understanding. )

And it WILL be used automaticly regardles if you think it should be or not. Thats what history chown us. Look at all the CDMs. Do you think people will not use it automaticly?

That is true....could be alot of innocent kicks/bans if it was scripted or used by alot of stupid operators.

However they always have 50% chance of kicking the guilty one

Post by **ullner** » 2004-10-26 14:12

Scope: why are you trash-talking one of the contributers to DC++? What have you ever contributed?

Scope · Post by **Scope** » 2004-10-26 14:29

ullner wrote:Scope: why are you trash-talking one of the contributers to DC++? What have you ever contributed?

Well im sorry, I was being sarcastic

cologic · Post by **cologic** » 2004-10-26 14:39

Always gratifying to know that you know what's best and are looking out for me.

And no, I don't buy the 'stupid == sarcastic' thing. You've used it in at least a couple other places directed towards me in this thread.

Twink · Post by **Twink** » 2004-10-27 03:50

I dont see how a 50% chance of kicking the guilty person is a good thing, infact i can see many people purposely abusing this system to try get people they dislike kicked.

Also have you thought about connection timeouts? and/or people disconnecting from the hub after they have the slot?

Scope · Post by **Scope** » 2004-10-27 21:06

Twink wrote:I dont see how a 50% chance of kicking the guilty person is a good thing, infact i can see many people purposely abusing this system to try get people they dislike kicked.

Also have you thought about connection timeouts? and/or people disconnecting from the hub after they have the slot?

Its only 50% when someone is trying to abuse the system (not reporting downloads), otherwise its as good as 100%. Hehe and you think ppl will get a client that doesnt report downloads and then start downloading from someone they dont like and then report them to the operator for faking?

This must of course be used with the setting "Automatically disconnect users who leave the hub". Connection timeouts are no problems, as soon as the user leaves the hub the connection is closed. So whenever the client is reporting an upload, the user will be in the hub.

Does anyone have any better suggestions on how to stop the slot-faking?

ivulfusbar · Post by **ivulfusbar** » 2004-10-28 00:19

Yes. Todo nothing. You will not be able to flush them out anywhy.

cologic · Post by **cologic** » 2004-10-28 09:00

Hehe and you think ppl will get a client that doesnt report downloads and then start downloading from someone they dont like and then report them to the operator for faking?

I suspect enough to disrupt your scheme.

Connection timeouts are no problems, as soon as the user leaves the hub the connection is closed.

You'd require this to be enabled? I consider the option outright broken at the moment and refuse to use it. I'm sure some thread explains why, but more or less it interacts poorly with slot limitations. It could be implemented better, but I still prefer leaving it unchecked: I don't wish to penalize people for leaving a hub.

For that matter, dedicated slots are a bad idea too, technical limitations or no. If people on a hub aren't currently trying to download, others should have access to that slot.

You'd sacrifice both of those (in ADC, of course. NMDC-protocol won't do it.), as well as introducing a mechanism that will be abused to kick innocent users, for the dubious benefit you've espoused? Maybe it's just me, but I've only rarely seen the problems triggering your post. The vast majority of DC users seem to share legitimately.

Edit: typo.

Post by **GargoyleMT** » 2004-10-29 10:56

Scope wrote:This must of course be used with the setting "Automatically disconnect users who leave the hub". Connection timeouts are no problems, as soon as the user leaves the hub the connection is closed. So whenever the client is reporting an upload, the user will be in the hub.

Doesn't that defeat the purpose of making the "auto-disconnect people who leave the hub" an option? Unfortunately, this has additional problems: users post about having too many upload slots open, due to the granting behavior of this feature. I was thinking of changing it so that it would disconnect a user if they've been out of the hub for 10 minutes - this should give most clients 3 chances to reconnect to the hub, in case of trouble with their ISP. It seems like the new proposed behavior would wreak havoc with your feature.

If you're serious about your feature, I suggest you start asking programming friends to code it and submit it to arnetheduck.

Scope · Post by **Scope** » 2004-10-29 12:23

GargoyleMT wrote: Doesn't that defeat the purpose of making the "auto-disconnect people who leave the hub" an option?

In my opinion ppl has no reason to keep connections outside the hub open. If they want to transfer something when not connected to the hub, then use FTP or something. You must have SOME rules!

GargoyleMT wrote: Unfortunately, this has additional problems: users post about having too many upload slots open, due to the granting behavior of this feature. I was thinking of changing it so that it would disconnect a user if they've been out of the hub for 10 minutes - this should give most clients 3 chances to reconnect to the hub, in case of trouble with their ISP. It seems like the new proposed behavior would wreak havoc with your feature.

If you're serious about your feature, I suggest you start asking programming friends to code it and submit it to arnetheduck.

Well the autogranting will not be a problem, all uploads should be reported, including granted slots, and the three extra slots for filelists and small files.

Of course I'm serious, the faking CAN be controlled! I have been modifying DC++ since version 0.163. My current modified version has the ability to read a chosen filelist and use that as a fake share. It uploads small files from the fake share, but its only crap in the files. But since its usually checked by bots and never checked by operators I have never been kicked for it. It even answers on searches in the fake share. You can set the version yourself. Tag is modifed and it uses random choosable nicknames on different servers making it a little bit harder to find you on two servers at the same time. Faking no slots available is of course an option in it. I have been using 1.5 TB shares in several hubs and not been kicked, I have been invited to private hubs by the operators. I have as good as NEVER been kicked/banned for faking, a few times I have been caught in two different hubs but reporting only 1, thats all.

Now I tried to offer my help to stop faking. And yes there are yet some problems to fix, but why flame my ideas when you havent got any better ones? Why just ignore the fact that alot of ppl are using clients like mine? This system isnt 100% but lets make it 100% then? For instance in the future, if the protocol is modifed, the hub could keep a random key for each connection, if you want to download something you need a key from the hub and then send it to the client you want to download from. That client requests the key from the hub and if its a match start the transfer. And let the clients report the random key as well when using the $upload command.

Scope · Post by **Scope** » 2004-10-29 12:29

ivulfusbar wrote:Yes. Todo nothing. You will not be able to flush them out anywhy.

Very nice attitude man! Do you reason the same about crime in the society? The legal system isnt always 100% sure, but we trust the judges and legal ppl to do the right thing from the evidence they have. We cant stop crime, should we just do nothing instead? If you dont like my idea, please come with a better one?

ivulfusbar · Post by **ivulfusbar** » 2004-10-29 12:35

If the hub goes down, should all transfers associate that hub stop between clients?
If so, i think many many users will become angry. Ok, so lets assume they shouldn't. That means that we will have alot of "spoke" connection when the hub restarts. You can't trust any of the feedback you get from the client to the hub stating which downloads/uploads are running before the hub crashed / was restarted... Ohh.. What todo then?

I can continue to come up with more and more objects to why your scheme is not working but i'll stop here. It all goes backs to, you can't trust clients to send you information that would harm themself. And keeping state of every message sent will for example break on restarts, reboots, timeouts...

And btw, i had a better idea. If there is no problem, then there is no point in fixing it. The number of people faking is far less than the number of users with useless shit in their share to me. Maybe 1 faker on 100 useless users. (Probably more)

Post by **GargoyleMT** » 2004-10-29 12:42

Scope wrote:Of course I'm serious, the faking CAN be controlled! I have been modifying DC++ since version 0.163.

Although I, as an American, have been forced to give up certain freedoms to prevent another terrorist attack, I am loathe to do the same thing with my DC++ client. (I regard who I'm uploading to and downloading from as private information, and I'd just as soon tell a complete stranger my social security number and birthdate as give them up.)

Scope wrote:My current modified version has the ability to read a chosen filelist and use that as a fake share. It uploads small files from the fake share, but its only crap in the files. But since its usually checked by bots and never checked by operators I have never been kicked for it. It even answers on searches in the fake share. You can set the version yourself. Tag is modifed and it uses random choosable nicknames on different servers making it a little bit harder to find you on two servers at the same time. Faking no slots available is of course an option in it. I have been using 1.5 TB shares in several hubs and not been kicked, I have been invited to private hubs by the operators. I have as good as NEVER been kicked/banned for faking, a few times I have been caught in two different hubs but reporting only 1, thats all.

We've had many discussions on our DC hub about faking, and the best way to do it without getting caught (this is good defensive programming). The scheme you describe above has a couple weaknesses:

1. $Supports strings with different versions are pretty easy to detect
2. If the hub enforces hashing, the small files must have TTHes and match them. (or it could be deteted by CDMs)

It's much better to clone someone's share and to download all of their small files, or strip the small files from the list before sharing them. Combined with slot blocking, this is nearly undetectable.

If DC++ changed its small file behavior so that if you requested a segment less than <small file size> from the end of the file it counts as a small file and uses a mini-slot, the form of sharefaking I just described would be much harder - you'd have to also get the end of each file, which adds to the cost of effectively sharefaking while emulating the current version.

And, of course, if hubs enforced a minimum client version equal to the current DC++ release... you could see what would happen.

You seem to have qualifications in faking. Please don't assume we lack in that area. We just disagree that your proposed solution will be effective.

Scope · Post by **Scope** » 2004-10-29 13:08

GargoyleMT wrote: We've had many discussions on our DC hub about faking, and the best way to do it without getting caught (this is good defensive programming). The scheme you describe above has a couple weaknesses:

Well there are limits on how much time I want to spend on a faking client. Yes the $Supports can rule out version mismatches if you keep a too old client. However its rather easy to fix those two points.

There are also limits on how much time I want to spend on discussing something that obviously nobody wants to fix.

Have a good one guys!

Post by **GargoyleMT** » 2004-10-29 21:33

Scope wrote:There are also limits on how much time I want to spend on discussing something that obviously nobody wants to fix.

Nice "All or nothing" thinking there.

Scope · Post by **Scope** » 2004-10-31 03:39

GargoyleMT wrote:
Scope wrote:There are also limits on how much time I want to spend on discussing something that obviously nobody wants to fix.
Nice "All or nothing" thinking there.

All or nothing? Did anyone of you come up with anything else than NOTHING ? NO.
So did I choose nothing? No YOU did. What else are the alternatives? You guys vote for nothing, at least I vote for something.

Nice "Getting the last word" thinking there!

Post by **GargoyleMT** » 2004-11-04 10:07

Scope wrote:Did anyone of you come up with anything else than NOTHING ? NO.

GargoyleMT wrote:If DC++ changed its small file behavior so that if you requested a segment less than <small file size> from the end of the file it counts as a small file and uses a mini-slot, the form of sharefaking I just described would be much harder - you'd have to also get the end of each file, which adds to the cost of effectively sharefaking while emulating the current version.

This would raise the disk cost of effectively share-faking to 64 kilobytes per large file, and whatever the sum of the small files was. It's an improvement. But it does rely on hubs enforcing use of recent DC++ versions. (So does your scheme, so this isn't a real fault.)

Scope · Post by **Scope** » 2004-11-04 11:08

GargoyleMT wrote:
GargoyleMT wrote:If DC++ changed its small file behavior so that if you requested a segment less than <small file size> from the end of the file it counts as a small file and uses a mini-slot, the form of sharefaking I just described would be much harder - you'd have to also get the end of each file, which adds to the cost of effectively sharefaking while emulating the current version.
This would raise the disk cost of effectively share-faking to 64 kilobytes per large file, and whatever the sum of the small files was. It's an improvement. But it does rely on hubs enforcing use of recent DC++ versions. (So does your scheme, so this isn't a real fault.)

And how would that help slotblocking? You can still keep a clean share and fake no slots available. Have a fake share without any small files or text files, and just send random shit if someone wants the tail of a file. How are you supposed to check the integrity of just the end of the file?

The slotblocking is the problem! If ppl cant fake no slots available, they cant have a fake share (at least not for long).

Now if you all think it cant be stopped due to limitations in the protocol, then start to think about what can be done about it in the future.

Scope wrote: For instance in the future, if the protocol is modifed, the hub could keep a random key for each connection, if you want to download something you need a key from the hub and then send it to the client you want to download from. That client requests the key from the hub and if its a match start the transfer. And let the clients report the random key as well when using the $upload command.

But I assume that nothing will ever be done to prevent slotfaking

Post by **GargoyleMT** » 2004-11-04 13:43

Scope wrote:And how would that help slotblocking?

You're right, it wouldn't do anything. It would only give CDMs enough tools to detect wether or not a given share is made up of real files or not. (My earlier estimate was wrong, it's 64kb per file, plus 24kb for the TTH leaves.) It raises the bar for a fake share pretty far above existing faking software.

Scope wrote:How are you supposed to check the integrity of just the end of the file?

For a small-ish files, TTH leaves can do this.

Scope wrote:For instance in the future, if the protocol is modifed, the hub could keep a random key for each connection, if you want to download something you need a key from the hub

This is interesting, but is moving the wrong way legally. It seems that if users required a unique key from the hub for each connnection, the hub owners could be held liable for what users exchange.

Scope wrote:But I assume that nothing will ever be done to prevent slotfaking

To my knowledge, nothing has been done to address slot faking (other than trying to ban DC++) since DC began (at least 4 years at this point). If there was a compelling solution, that would be a different story.

DC++

Time to END the slot-faking

Time to END the slot-faking

Re: Time to END the slot-faking

Re: Time to END the slot-faking