[BitTorrent] BT2 & hash trees
painlord2k at libero.it
Fri Jul 23 15:42:13 EDT 2004
Elliott Mitchell wrote:
>This assumes you can find the same file on their networks. Possible, but
>highly non-trivial. This would also require a lot of work to keep them
>Does anyone have plans to implement such a feature on any client? I
>suppose it is a thought, but I'm *very* doubtful of the usefulness.
Shareaza already implement Gnutella/G2/eDonkey2000/BitTorrent protocols
It can also search for alternate sources for dead torrents using G2.
If BT2 implement standard THEX and standard hashes it could work even
better than now.
Now, it is very difficult/near impossible to recover a dead multi-files
torrent (because there are no single hashes for the files).
With this type of features this could be easy search for alt-sources (a
simple search for hash).
>These are also going to be tiny packets. 40 bytes for the IP and TCP
>headers on *each* request. If there is other traffic on this connection,
>then it can be combined together and save bandwidth, but this will harm
>latency (oops, can't win).
Then don't request only two hashes but four or eight or ...
THEX is there for manage this.
>True, but I must bring up the question of whether it is even worth
>bothering attempting to verify 1KB blocks, even if you have that ability.
>All existing BitTorrent clients transfer data in blocks of 16KB or 32KB.
>As a result, every 1KB sub-block of a 16KB block is going to of come from
You have the root hash of the 16 KB chunk in the THEX standard, then you
can check this chunk.
No need to check under this.
The question is "because develop a custom Merkle tree when THEX is
To save a few CPU cycles?
>Enemy action is far more likely to produce failures that don't get caught
>in the network stack. In a case like this is enemy going to bother only
>damaging 1KB and send the other 15KB to you intact? Why not send as much
>corrupt data as possible, and cause the most damage possible? In this
>case it is *highly* unlikely that *any* of the data this peer has sent to
>you is valid; so why bother verifying 1KB sub-blocks when almost
>certainly the *entire* 16KB (or 32KB with some clients) block that was
>sent is bad?
>Does this kill 1KB verification for you?
Not for me, because your assumption on the enemy are wrong.
The enemy will not try to poison small verifiable chunks (16 or 32 KB),
because it is not cost effective
Then you don't need to store and exchange hash data about 1 KB chunks.
You only store and exchange the fifth level of the tree (16 KB) and
Is it really different using SHA1(16KB) from THEX(SHA1(16KB)) for you?
>>Here is where I gain something if the block size used in BT is the one I already
>>use: If I create a torrent for any file with my software, I will not even
>>recompute the hashes to create the torrent but use my default hash tree. In case
>>the tracker fails, I can easily query a p2p network (in my case that would be
>>Gnutella) for the root hash of a file because this root hash will be created by
>>default by any node in the network. Of course I could also use a non-standard
>>extension to the torrent file I create but that would not be in my best interest.
>I have to doubt someone who is grabbing torrents will want to bother with
>another P2P network.
Again SHAREAZA bother.
And a few other I suppose
I saw this arguments many times if the past years.
They don't endure scrutiny.
------------------------ Yahoo! Groups Sponsor --------------------~-->
Make a clean sweep of pop-up ads. Yahoo! Companion Toolbar.
Now with Pop-Up Blocker. Get it for free!
Yahoo! Groups Links
<*> To visit your group on the web, go to:
<*> To unsubscribe from this group, send an email to:
BitTorrent-unsubscribe at yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
More information about the BitTorrent