Durabit: Incentivizing Torrent Seeding With Bitcoin

BitTorrent has been around for 22 years as of this year. In many ways it is a technology protocol almost as big as Bitcoin in the scope of how it changed the game of moving data around the internet. If Bitcoin is the money for sending money around when people don’t you doing so, BitTorrent is the mechanism for moving data around when they don’t want you to. It’s always had a big problem though, one I’m sure anyone who has ever used it is quite familiar with. The seeding problem.

How many of you, upon completing the download of a file, have immediately closed out your torrent client and didn’t leave it seeding after you had the complete file? Everyone has done it. BitTorrent doesn’t function without users staying online and seeding a file for others to download, which most users do not do for very long after attaining the complete file. This works whenever a file is in very high demand, people seed the sections of the file they have as they download, they disappear when they’re finished, but in the meantime other people come online and start downloading, and they also seed as they download. It works as long as the group going through that churn is large, but if it isn’t torrents tend to fade away and become unavailable as people stop seeding.

This presents a problem for the longevity of individual torrents. It is a great protocol for getting a piece of data circulating while it is in high demand, but after that demand fades that data tends to become unavailable as people stop seeding it. Durabit is a recent proposal to attempt to address this issue. The scheme is relatively simple, but seems like it would provide a solid incentive mechanism for people to keep seeding a file.

The system depends on a chaumian ecash mint to facilitate the incentive mechanism for file seeders. A third party who wishes to ensure a file stays available enters into a contractual arrangement with the ecash mint, taking the form of a series of timelocked pre-signed transactions. Each transaction is timelocked in intervals of two weeks, and pays out a small amount each time to the chaumian ecash mint. Each payout is a timelocked UTXO that cannot be spent until the next transaction becomes valid, with the remainder of the funds always going back to an address controlled by whoever issued these transactions, with the next transaction in the chain spending this change output.

The first transaction in the series commits to a specific torrent magnet link in an OP_RETURN output to associate the contract with the file the issuer wants to incentivize seeding. After the mint has these pre-signed transactions in its possession, it submits the first transaction to the chain and begins monitoring the torrent swarm for the specified magnet link. From here the mint listens for any torrent clients that also run a Durabit client to reach out to it. If any Durabit client pings the mint from the same IP address as someone it sees seeding in the torrent swarm, it maintains that connection out of band.

From here the mint watches and tracks seeders that have registered with it. During the course of the two week period before its most recent payout becomes spendable, the mint issues chaumian ecash tokens to each registered seeder for keeping the data available. A mint can do this proportionally to the amount of data seeded, or can randomize token issuances in a lottery amongst the seeders it has registered. Once its payout output becomes spendable, it can announce this and open a redemption window to payout the actual bitcoin in exchange for chaumian tokens it has issued during that seeding epoch. This cycle continues for as long as the series of pre-signed transactions lasts. The overall total amount of bitcoin contributed to the contract, and the amounts paid out each period, are entirely up to the issuer of the contract.

I’m sure most of you are thinking “what stops the chaumian mint from simply just collecting these payouts and not distributing a portion of them to the people seeding the torrent?” This is the beauty of the proposal: purely incentives. Each transaction pays out a small amount of funds to the chaumian mint in a timelocked output, and spends the rest back to the issuer of the contract. At any time the party that issued this contract can effectively revoke it by double-spending that output, invalidating the rest of the pre-signed transactions from that point forward. The mint, being aware of this, has to weigh the potential loss of all future income derived from any individual contract by collecting the agreed upon percentage of each payout for itself against the potential gain of keeping an entire payout while losing that percentage fee for all future payouts.

The issuer on the other hand was initially motivated to issue the contract in the first place because of a desire to keep a specific file available by incentivizing people to seed it. If they truly want that file to stay available, it is in their best interest to not revoke any contract they have issued unless the mint fulfilling it is acting dishonestly. This arrangement aligns the incentives properly so that it should be in the best interest of the mint to monitor the torrent swarm and distribute funds honestly to seeders, and it is in the best interest of the issuer of the contract to not double-spend it and revoke it so long as the mint continues operating honestly.

The proposal looks at the problem of actually auditing honesty, both in terms of the mint auditing seeders it is distributing tokens and payouts to, and the issuer of the contract auditing the mint. In the case of a mint auditing a seeder, they can select random chunks of the torrent file to download periodically. This should provide a decent assurance that any individual seeder is actually in possession of and serving the file to other users. In the case of the issuer auditing the mint, indirectly monitoring the torrent swarm should provide a good enough basis to assess the mint’s honesty. Once a contract has begun, and the mint has started issuing payouts, the swarm should establish a baseline of traffic proportional to the economic incentive the contract provides. If at any time the issuer notices a large decrease in swarm traffic, that is a pretty good indicator that the mint is not processing distributions honestly and the contract should be revoked.

Neither of these are foolproof, especially in the case of the mint auditing the torrent seeders, but they should be good enough. At the end of the day if a seeder is essentially just grabbing data from other seeders to respond to challenges from the mint, in order for them to do that the data does need to be available enough for them to grab any random chunk the mint challenges them to produce. So in such an instance, while actors may be able to dishonestly collect payouts from the mint without hosting and serving the file, if the file is not actually available they would be incapable of gaming the system in that way. I don’t believe this is a fatal flaw, as the overall goal of ensuring the files availability is still met.

Overall Durabit is a very simple system facilitated by a trusted party in the form of the chaumian mint, but I think that simplicity is its strength. The amount of funds ever available for a mint to abscond with maliciously is minimal, and if such an event were to occur the issuer of the contract can simply revoke the existing one and re-issue it with another mint. I think it provides a very simple and elegant solution to the incentive problem of keeping files seeded using BitTorrent even during huge drops in demand from users.