Quote from: DarkFox on September 03, 2014, 03:57:53 AM

Hello,

As I said on IRC, this is a great idea; but scalability is a huge problem.

" FrozenBytes [because once's it's uploaded it'll never go away] (Name can change don't get mad at this plz) A decentralized file sharing platform. "

Never? Frozen alright... Free upload? Trivial to fill the network's storage capacity essentially creating a DoS attack that can only be revived by (1) restarting [lose all the files] or (2) expanding [how much can you expand with an active attacker always uploading junk?]

" JUST REALIZED THERE COULD ALSO BE METHODS TO MAKE IT HARDER TO PIRATE PAID FOR STUFF. We could entirely encode stuff with the tx. If a file has that tx byte or whatever still in it we could have stops in place to prevent it from being re-uploaded. A better system of creators protection (Blah blah blah fuck copyright... Don't care... These are ideas roll with it.) "

Yea... No. If someone wants to reupload a file; they simply need to change any single bit they desire. If this is an image or a song, most of the bits may be flipped to bypass the basic deduplication from the hash function.
This could be changing a colour from #000000 to #000001, the user can't see any difference. Another method that the pirate may use without affecting the quality, would be to simply add null padding to the end of the file.

" Also to prevent people from downloading what is effectively 100% porn we could include previews for songs/images? "

Should the uploader decide to include previews, there is no way to know that the "thumbnail" or cut down audio track are even the original file.

With a song, however, you may reduce overhead of another copy by splitting the content. Below, k1 = public, k2 = premium (pay-for).

90 second song = decrypt(k1,[30 seconds]) + decrypt(k2,[60 seconds])

Here, there is no integrity for the last 60 seconds, the user may check the first 30 and it may be the right song and they pay, to find the 60 seconds were fake.

" Once this is done you'll see your username (ADDRESS) and password (PRIVATE KEY) you'll use this to login. P.S. I just effectively made it theoretically impossible to hack accounts. "

Username = public key
Password = private key

Oh, so no username; as the public is derived from the private. The public identifier for the user is simply addressable. The point here, is that the file isn't protected by both user+pass, but instead just pass. Where this key is only a 256-bit key.
Yes, yes, 2^256 is a good keyspace for a secure key and it does scale well. I'm just clarifying this here, it's only 2^256, not 2^256+2^160 (private+public). Should the curve and keyspace ever in the future be broken (so far; we don't know any effective attacks*) then all data would be public to all (and we can't delete it \o/).

Theoretically? No. Cryptographically, maybe? Such that you define something cryptographically secure by the fact that it's computationally difficult enough that it would take an aweful lot of time (I.e. 10s of years)

*: A brute force attack isn't effective, it's iterating over every possible key (slow), an effective attack would involve reversing the math; which with ECDSA on Bitcoins' curve of choise secp256k1 is currently cryptographically secure.

Payment..... Lets just talk on IRC about this.

Alice pays bob for content.
Bob must be online to confirm to send alice the secret; this is worse then an unseeded-torrent.
If the network can send alice the key without bob; then Alice can do the same without the network

Cheers, DarkFox.

Thanks, I hope to work with the developers and YOU on the IRC to fix some of these issues.

Likewise REMEMBER SOME OF THESE ISSUES ONLY AFFECT STORE FRONTS.

And the antipiracy thing isn't perfect, just thinking of ways to maybe make a more stable environment of non-duplicate files.