BitTorrent has been around for 22 years as of this year. In many ways, it’s a technology protocol almost as big as bitcoin in the realm of how it changed the game of moving data over the Internet. If bitcoin is the money for sending money when people don’t want you to, BitTorrent is the mechanism for moving data when they don’t want you to. However, it has always had one big problem, one that I’m sure anyone who has ever used it is quite aware of. The problem of sowing.
How many of you, upon completing a file download, immediately closed your torrent client and didn’t let it seed after you had the complete file? Everybody has done it. BitTorrent does not work without users staying online and submitting a file for others to download, which most users do not do for a long time after obtaining the completed file. This works whenever a file is in very high demand, people initialize the sections of the file they have as they download it, they disappear when they’re done, but in the meantime other people come online and start downloading, and seed it as well that download it. discharge. It works as long as the pool going through that rotation is large, but if it’s not, the torrents tend to fade away and become unavailable as people stop seeding.
This presents a problem for the longevity of individual torrents. It’s a great protocol for circulating a piece of data while it’s in high demand, but after that demand drops, the data tends to become unavailable as people stop seeding it. It will last is a recent proposal to try to address this problem. The scheme is relatively simple, but it seems like it would provide a strong incentive mechanism for people to keep generating a file.
The system relies on a chaumian ecash mint to facilitate the incentive mechanism for file seeders. A third party who wishes to ensure that a file remains available enters into a contractual agreement with ecash mint, which takes the form of a series of time-limited, pre-signed transactions. Each transaction is locked at two-week intervals and pays a small amount each time to the chaumian ecash mint. Each payment is a time-locked UTXO that cannot be spent until the next transaction is valid, and the rest of the funds always return to an address controlled by whoever issued these transactions, and the next transaction in the chain spends this result exchange.
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. Once Mint has these pre-signed transactions in its possession, it sends the first transaction up the chain and begins monitoring the torrent swarm to find the specified magnet link. From here, Mint listens to any torrent client that is also running a Durabit client to communicate with it. If any Durabit client pings mint from the same IP address as someone they see seeding the torrent swarm, they keep that connection out of band.
From here, the Mint monitors and tracks the planters who have registered with it. During the course of the two-week period before your most recent payment can be spent, the Mint issues chaumian ecash tokens to each registered sower to keep data available. A mint can do this proportionally to the amount of seeded data, or it can randomize the issuance of tokens in a lottery among the seeders it has registered. Once your payment production can be spent, you can announce it and open a redemption window to pay the actual bitcoin in exchange for chaumian tokens that you have issued during that seeding time. This cycle continues for as long as the series of pre-signed transactions lasts. The total amount of bitcoins contributed to the contract and the amounts paid in each period depend entirely on the issuer of the contract.
I’m sure most of you are thinking “what’s stopping Chaumian Mint from just collecting these payments and not distributing a portion of them to the people who seed the torrent?” This is the beauty of the proposal: purely incentives. Each transaction pays a small amount of funds to the chaumian mint in a limited period of time and spends the remainder to the contract issuer. At any time the party that issued this contract can effectively revoke it by double spending that production, invalidating the rest of the pre-signed transactions from that moment on. The Mint, aware of this, has to weigh the potential loss of all future income derived from any individual contract by collecting the agreed percentage of each payment for itself against the potential gain of keeping a full payment and losing that percentage for everyone. future payments.
On the other hand, the issuer was initially motivated to issue the contract in the first place due to the desire to keep a specific file available by incentivizing people to initialize it. If they really want that file to remain available, it is in their best interest not to revoke any contract they have issued unless the mint fulfilling it is acting dishonestly. This agreement aligns the incentives appropriately so that it is in the Mint’s best interest to monitor the torrent swarm and distribute the funds honestly to the seeders, and it is in the contract’s best interest to not spend it twice and revoke it as long as the Mint continue to operate honestly.
The proposal looks at the problem of auditing honesty, both in terms of the mint’s audit seeders to whom it distributes tokens and payments, and the contract issuer that the mint audits. In the event that a mint audits a seeder, it can select random chunks of the torrent file to download periodically. This should provide a decent guarantee that any individual seeder is actually in possession of the file and delivering it to other users. In the case of the issuer auditing the mint, indirect monitoring of the torrent swarm should provide a good enough basis to evaluate the honesty of the mint. Once a contract has begun and the Mint has begun issuing payments, the swarm must establish a traffic baseline proportional to the economic incentive the contract provides. If at any point the issuer notices a large decrease in swarm traffic, it is a good indicator that the mint is not processing distributions honestly and that the contract should be revoked.
None of these are foolproof, especially in the case of Mint auditing torrent seeders, but they should be good enough. At the end of the day, if a planter is essentially simply taking data from other planters to respond to Mint challenges, in order for them to do that, the data must be available enough that they can capture any random portion of the Challenges of the Mint. them to produce. So in such a case, while actors can dishonestly collect payments from the mint without hosting or delivering the file, if the file is not actually available, they would be unable to game the system in that way. I don’t think this is a fatal flaw, as the overall goal of ensuring file availability is still met.
Overall, Durabit is a very simple system provided by a trusted party in the form of chaumian mint, but I think simplicity is its strong point. The amount of funds available for a mint to maliciously escape is minimal, and should such an event occur, the contract issuer can simply revoke the existing contract and reissue it with another mint. I think it provides a very simple and elegant solution to the incentive problem of keeping files stored using BitTorrent even during large drops in user demand.
