BitShares Forum
Main => General Discussion => Topic started by: 8bit on December 13, 2013, 05:00:46 am
-
I find the concept behind datacoin to be really interesting, but I feel it has a bit of a problem. A blockchain is a very clunky way to store rich, human consumable data. Even storing a short book is a daunting task for something like datacoin, storing a whole album, film, or video game is ridiculous. Everyone who uses datacoin would have to download every film, game, etc... that anyone wants to share! What if we leveraged the power of an existing decentralized technology to do the heavy lifting for us?
BitTorrent is a much better protocol for distributing data than a cryptocoin. Instead of using a monolithic blockchain that everyone needs to have a copy of, only the people interested in a file need to worry about it. Unfortunately, BitTorrent has a bit of a problem. Though the underlying technology is decentralized, it has been impossible to completely decentralize data transaction in BitTorrent.
There has certainly been progress, don't get me wrong. In the old days, centralized websites had to host .torrent files- files that would link to a tracker (a centralized server), which would connect new members of the swarm to other members. Today, recent breakthroughs in distributed hash tables have lead to a less centralized way of doing things. Rather than using a centralized tracker users obtain magnet links which are like IDs for torrents. Each member of the BitTorrent network holds a hash table containing the IPs of a small number of nodes on the network. The user with the magnet link sends a request through the network by sending it to one of the IPs listed in her hash table. That node does the same thing, and so on, until a node which is a member of the correct swarm is discovered. This cuts the tracker out of the equation, but there is still a need for a centralized database of magnet link listings. This is why sites like The Pirate Bay still exist. The Pirate Bay is not a tracker anymore, but it's still needed to find the actual magnet links. Still, this is a huge improvement. Now TPB no longer needs to manage the individual users in a swarm, now its only purpose is serving up static information. This means that other users can make backups of TPB, and use those backups to find magnet links. The more people with up to date backups, the less centralized TPB's listings are. And if everyone has an up to date copy of the TPB database...
That's where the blockchain comes in. I think the blockchain may be the final puzzle piece in distributed and decentralized file transfer. The blockchain is, effectively, a database that everyone has, and where new information propagate through the network very quickly. A blockchain is limited in that old data is read only, but that will be fine for our purposes, as most of our blockchain data will be static and/or simple. My idea is that the blockchain would list, not just transactions broadcast to the network, but also magnet links and metadata about the magnet links. (title, description, tags, etc...) A user who wants to download a torrent would search his blockchain for the magnet link, broadcast the link to the BitTorrent node network, locate the torrent's swarm, join the swarm, and download/share the file from/with the swarm.
Like any chain, when blocks are mined a certain number of coins are released to the miner. Much like with datacoins, these coins can be spent to include new data in the blockchain. As the amount of information contained in the magnet link itself is very small, the cost to list a new link should also be very small. To illustrate how small magnet links are and how cheap storing them in a blockchain would be, consider this: If we decided to store all of the data on the pirate bay on the datacoin chain it would cost less than 10000 datacoins, including metadata but not comments. With around 1,700,000 torrents, that's around 0.006 datacoins per torrent.
In order to incentivize seeding, The Hive client sets a default badwidth cost, some arbitrary value, say, 0.0001 hivecoin/kb. A random Hive node is chosen to act as an escrow agent, which receives a large chunk of the payment all at once (Say, 10MB worth) along with the transaction fee, and a small escrow fee. The leacher starts compiling a table that details all of the data he's received. At certain arbitrary intervals, say, once every ten minutes, the table is sent to the escrow detailing all of the data transactions. The escrow releases funds accordingly. If the escrow never receives the table, or if there is extra left over at the end then the escrow keeps the extra.
As the blockchain is aware of all messages to the escrow, there is no risk of the escrow running off with the coin. The blockchain simply moves around the escrow funds on its own. Pending escrow funds wouldn't even show up in an escrow's wallet until some arbitrary and long period of time has passed during which the blockchain has not received contact from the leacher. The escrow service could even be used to reward network nodes, something that bitcoin doesn't manage to do.
In summary, this is an idea for an altchain which completely decentralizes file sharing by creating a listing of torrent magnet links within the blockchain. This replaces the need for centralized listings like The Pirate Bay. The Hive also incentivises seeding which keeps swarms healthy, and incentivises running a chain node which keeps the network healthy.
Possible modifications:
- Would it be possible for users to issue corrections to inaccurately titled or tagged listings by adding new data to the next block being mined which lists a set of changes and points to the block containing the incorrect listing? Could this be used to rate and comment on torrents? Could this be used to put an updated number of seeders/leachers for every listing in the newest block of the blockchain?
Possible alternatives:
- As mentioned, datacoin attempts to do a similar thing, but in a more generalized sense. The Hive could effectively lie within the datacoin blockchain, however, the issue with that is that then every user has to put up with every item added to the blockchain. So if someone buys space for a film, everyone has to host that film forever. The Datacoin developers seem to want to go in this direction, encouraging users to set up wallets dedicated to particular large data files and ask for donations in order to get them added to the blockchain. My idea would only allow for torrent magnet links and metadata, so the blockchain would stay slim, and large files could get listed for very cheap. Datacoin does hold the advantage that it immortalizes data, whereas torrents can die if all of the seeders disappear.
- Freenet attempts to do a similar thing, but it is on the other extreme from datacoin. Rather than storing all of the information locally on the blockchain, all of the information is distributed throughout the entire network. This offers an advantage in that no blockchain ever needs to be downloaded, however, it also carries the disadvantage that it is very slow because information can be located anywhere on the network. Compare to a blockchain where no Internet access is required to retrieve the file, and to torrents where users interested in the same files are organized into decentralized swarms.
Potential issues:
- If seeding is not incentivized then the blockchain would be technically superfluous. This isn't really an issue, but it's something to think about, as other types of distributed databases might be better suited for this project. That said, datacoin is already very technically similar to what I'm describing, so development may be more rapid as an altchain than as a different type of database.
- The blockchain would store not just magnet links and metadata, but also a ledger of all Hive transactions. If we used a different type of distributed database which did not track a currency of any sort, then the database size would be much, much smaller. In fact, the actual magnet links would take up a minority of space compared to the transaction ledger. We're talking MB vs. GB, a difference that is several orders of magnitude large. One solution to this is the creation of a litewallet which only holds the magnet links and recent transactions. This type of wallet would only be a few MBs large, but it wouldn't be able to act as a node. Multibit takes this strategy.
- The blockchain does not allow for older data to be overwritten. Like I've said earlier, this isn't too much of an issue as magnet links are static data, but it would be nice for tags, descriptions, etc... Also, it would be nice to be able to remove some older magnet links which don't have swarms any more. There are ways around this, but they involve bloating the blockchain even more. Rather than overwriting data, you must include both the new data and every old version of the data in the blockchain.
I'm mostly looking for feedback, here. How hard would it be to include the possible modifications I listed? How hard would the base implementation be? Are there any caveats (technical or economic) that I'm missing? Etc...
-
I like this concept, I was thinking a similar method could be used for implementing a Media DAC (think liberman's thinking along these lines as well) or the Media DAC could "rent" services from Torrent DAC to use for it's distribution mechanism. I think this idea could could (and should) be implemented ASAP as it has huge potential.
-
http://piratebrowser.com
Interesting development
-
http://piratebrowser.com
Interesting development
PirateBrowser is cool, but it's a bandaid, unfortunately. All it does is allow people in countries where the TPB IP has been blocked to access TPB by routing through the Tor network. If blocking TPB became popular, it would lose its effectiveness as there would be very few suitable exit nodes.
-
http://piratebrowser.com
Interesting development
PirateBrowser is cool, but it's a bandaid, unfortunately. All it does is allow people in countries where the TPB IP has been blocked to access TPB by routing through the Tor network. If blocking TPB became popular, it would lose its effectiveness as there would be very few suitable exit nodes.
True true