Writing a new protocol with an open source reference implementation will probably be a better idea, because:

1) Reverse-engineering isn't clean and can be circumvented.

2) BTsync has not reached a point where it can't be beaten by a competing protocol.

We're actively developing an open source Dropbox type app that's powered by Tent (https://tent.io).

you should have a landing page with an email sign up form that you can link people to.

Tahoe-LAFS is a mature project of this nature: https://tahoe-lafs.org/

I am writing a similar project which is fairly immature: https://github.com/cryptosphere/cryptosphere

The particulars of the BT protocol are beyond me, but I thought it would already do a compare between the copy you had and the one on the external server, and only send the relevant bytes to bring everything up to sync again.

Between that and a "compare timestamps to figure out the newest file" I wouldn't think it would be that hard to re-create? What am I missing here?

BitTorrent creates a hashes of your file. The file is broken down into certain size chunks and hashes taken of each chunk. If you already have a piece with a given hash, you won't download it. If a hash differs, it'll be transmitted. The receiver verifies the hash. If it fails it re-requests that piece.

I assume the sync protocol works the same. It hashes the file, checks if any chunks have changed, sends the hash meta-data to the recipient, who then requests and pieces that have changed.

What about hash collisions?

SHA-2 has no collisions found as of yet [1]. The collision attacks on md5 required a lot of junk data, so not sure how much of a problem that would be.

[1]: https://en.wikipedia.org/wiki/SHA-2#Comparison_of_SHA_functi...