the title of the thread is "limewire (3.8.9, 3.8.10, 4.0.4) downloading from bearshare (4.5.0bXX)." what more limewire version info do you want?
from the bearshare forum thread, posted by "pve", whoever that is:
"It won't be fixed. This 10-bytes overhead is not a bug, but needed for checking fast sources that incorrectly return fake SHA1 values."
talk to john lindh. he apparently (read the bearshare forum thread) DID determine that limewire is being confused by a shareaza (x-available-ranges) bug. later, we realized that there was a similar bearshare bug (modifying a file that's already being shared can fail to change the file's advertised hash on SOME versions of bearshare - but not the version i'm running).

in other words, one or more (buggy) bearshare sources may be advertising the same hash even though the file is different (longer) on those sources than on my source. limewire should know both the hash and size advertised by all sources. if hash1 == hash2, but size1 != size2, they're obviously not the same file. limewire should realize that. the hash CANNOT uniquely identify files - you need the size. of course, even then, it's possible to have hash1 == hash2 and size1 == size2 and still have different content, because the hash contains less info than the file itself - but different sizes obviously means different files, regardless of hash.

or it could simply be some other kind of limewire bug, where when there are exactly 10 bytes left in the source, limewire comes up with some weird-*** end-of-last-chunk value. the limewire request/bearshare response pairs captured and posted in the bearshare forum thread seem to support this theory.

please understand the problem before considering or rejecting potential solutions.