IP Encryption

[waza00]

y not have IP Encryption instead of passing ip addressees you use encrypted key's instead. when you load you're bit comet client it generates a encryption key and that stays with you will you use bit comet or something along those lines

[greywizard]

Because BitComet uses the open protocol named BitTorrent which is used by ALL the other BitTorrent clients out there and whose specifications are NOT controlled by BitComet's development team.

They just make sure that their client fully complies to those specifications so that it can communicate with all the other clients out there.

Therefore, doing what you ask for, would mean starting a P2P network different from the BitTorrent Network and not being able to access the resources available on the BitTorrent Network anymore.

[waza00]

maby so but if p2p docent move with the time's there wont be p2p. if you have a option to turn it on and of like protocol encryption you just have to change the ip protocol to accept encryption instead of ip addresses.

[kluelos]

"docent"? Did you mean, "doesn't"?

(If you can't competently use the tools of your native language, can't be bothered to learn to spell or even to use a spell-checker, I wonder what else you've overlooked or couldn't be bothered to check first? It makes anything that you advocate very suspect.)

IP addresses aren't hidden inside the torrent protocol, they're in the packet structure itself. The TCP/IP packets? Those?

Each link in the chain between source and destination, each "hop", receives a packet, looks at its destination IP address, figures out what would be the closest hop to itself in the direction of that destination IP, and sends the packet onward. That's how the internet works and how packet-switching works.

Every system at every hop needs free access to the IP address to do this. You cannnot encrypt it without disaster following. The system at the first hop looks over the packet, takes the first four bytes whatever they are, and takes them as the destination IP address whether you intended them to mean that, or not. It then sends this packet in some wildly wrong direction, toward the address indicated by those bytes, and the second through nth hops do the same thing until the packet either gets where it's going, or its time-to-live expires. When it gets there (NOT where you intended) the destination system can't make any sense of the content, so NAK's it. It takes the fifth through eighth bytes as the source address, so sends the NAK there. That other address, if it exists, gets the NAK, thinks, "I never sent him anything.", so doesn't know what to do with it and drops it.

This kind of byte structure used to be extremely common, before the advent of name/value pairs, back when memory and storage were at a premium. Files had byte-structure and knowing this was a black art. -- the eighth byte always means the subtype, so you can take a sector editor and change the subtype if you know what you're doing. You cannot change the meaning of the eighth byte. If you try, then this file is no longer compatible with the previous filetype, for all the existing versions of the application will still treat the eighth byte as the subtype. This also meant that you couldn't have more than 256 subtypes, and if you eventually just had to have more, you went through agonies of trying to deal with the issue yet keep the file structure compatible with older versions of the software.

If you could dope out the file structures you could do all sorts of forbidden wizardry with a hex editor and a little patience.

Byte structures of this kind are the how the internet was built, and nobody can "move with the times", change it to anything else without breaking the network or, more practically, just cutting themselves off from it.

Every major hop is owned by somebody else, and they're all independent cusses who won't agree on anything. It's anarchy, good luck trying to change the protocol.

They own the computers and you can't make them do anything they don't want to. Any serious change would require a miracle of cooperation between people who seldom agree. It never happens no matter how badly it's needed -- and it's been needed really, really badly for a long, long time. We needed to change the mail RFC to enforce basic authentication. That's been needed urgently for at least twenty-five years, in order to curb email spam. It's never happened. And that wouldn't require nearly as many people to agree.

And you will always, always, always find some crusty old SOB who says "the old way was good enough for me, and I'm NOT changing! Any of this new email that goes through MY system will just get thrown away!"