“KopperCoin—A Distributed File Storage With Financial Incentives”, 2016-11-05 (; similar):
One of the current problems of peer-to-peer-based file storage systems like Freenet is missing participation, especially of storage providers. Users are expected to contribute storage resources but may have little incentive to do so. In this paper we propose KopperCoin, a token system inspired by Bitcoin’s blockchain which can be integrated into a peer-to-peer file storage system.
In contrast to Bitcoin, KopperCoin does not rely on a proof of work (PoW) but instead on a proof of retrievability (PoR). Thus it is not computationally expensive and instead requires participants to contribute file storage to maintain the network. Participants can earn digital tokens by providing storage to other users, and by allowing other participants in the network to download files. These tokens serve as a payment mechanism.
Thus we provide direct reward to participants contributing storage resources.
[Keywords: blockchain, cloud storage, cryptocurrency, peer-to-peer, proof of retrievability]
…3.4: Fetching Files: In order to fetch a file the client application needs to know the identifiers of the corresponding chunks. The file is restored by retrieving sufficiently many chunks. For successful retrieval not all chunks have to be fetched, depending on the erasure code that was applied before storing the file in the KopperCoin-network. The erasure code solves the problem of missing chunks and storage providers demanding unrealistically high prices for chunk retrieval.
Fetching chunks works with 2-of-2 multi-signature transactions. These are transactions which can be spent if and only if 2⁄2 parties agree to spend them. To our knowledge the mechanism was first used by NashX23.
Let U be a user who wants to retrieve a chunk which is stored at the provider P. Suppose U wants to pay the amount p for retrieving his file. Then U and P create a 2-of-2 multi-signature transaction where the user U inputs β+p and P inputs α. The amounts α and β are security deposits. In a next step P sends the chunk to U. The user U checks if he has received the correct chunk. In that case he signs a multi-signature transaction with 2 outputs: The provider P gets back his security deposit α, together with the price p for the chunk. In the other output the user U gets back his security deposit β. The process is illustrated in Figure 1. Above the arrows are the amounts and below the arrows are the owners of the respective amounts.
If U wants to cheat he cannot set his security deposit β to zero or otherwise change the first transaction since this will be detected by the provider P who then refuses to sign. Nevertheless the user U can refuse to sign the 2-of-2 multi-signature transaction after retrieving the chunk, thereby losing his security deposit β.
If the provider P cheats he can either refuse to send the chunk or refuse to sign the 2-of-2 multi-signature transaction. In both cases he will suffer a financial damage of his security deposit α and not receive the price p for retrieval of the chunk.