Regarding data being taken hostage when retrieved

#1

I was reading the specs on Github and I had come up with a few questions. If the storage node refuse to give back the data to the retrieval node will the storage node get punished? Also what if the retrieval node is malicious and falsely reports the storage node is not giving back the data?

#2

If a storage client is worried that their data might be taken hostage, they should apply Erasure Coding (aka Forward Error Correction) to it and spread those pieces across several different storage miners. The choice of erasure coding, and number of deals should reflect the degree to which the storage client is afraid that their data be taken hostage.

There is no means “report” or authority to report to, that a storage node is not giving data back, however, failure to fulfill the storage contract means the storage miner would not be paid. So basically, the highly concerned client should 1) ensure that the data is stored with more miners, and 2) encrypt pieces uniquely so that no one can tell if it is or is not the same as another.

1 Like
#3

Thanks for the reply. I can see your solution makes sense. Based on this I have a few more questions.
So if there is no way to report if a storage node is not giving back the data, isn’t not sending back the data to the retrieval node the dominant strategy for storage node (assuming storage node and retrieval node is owned by different parties)? As sending back data requires upload bandwidth for the storage node, and the storage node is not getting anything back in return (or at least I didn’t see anything mentioned anywhere for this, correct me if I am wrong).
Also is there a Proof of Retrieval Speed? Since the storage node could have 1Gbps download but only has 1Mbps upload (I can see that the user can replicate the data on multiple nodes, but unless the storage node is paid somehow there is no incentive for the storage node to maintain its upload bandwidth unless the storage node and retrieval nodes must be owned by one party).

#4

It sounds like you are thinking that the storage miner gets paid only if they are also a retrieval miner. That is not the case. Storage miners do receive payment for storage.

As for the second part of your question, no there is no Proof of “Retrieval Speed” i.e. bandwidth, or delivery time.

#5

Thanks for the reply. I just wanted to clarify my question a bit. So does the storage miner receive payments for sending the file? Since the storage miner does receive payments from payment channels for storing the file, but do they receive any payments for sending it (to retrieval miner)? If not then there is no incentive for storage miner to send files, they can simply push proofs to the chain claiming rewards from the payment channel and never bother with any retrieval request.

#6

So does the storage miner receive payments for sending the file?

Yes this is an explicit goal of the protocol. It seems like you’ve noticed that this is not implemented yet in go-filecoin. It is coming up in a future release. Also the retrieval spec is currently a bit of a stub, but you can expect to see more articulation there in the coming months.

2 Likes
#7

The problem of Bob returning data to Alice so that it is unprofitable for either Alice or Bob to cheat is interesting. Along with the decentralized storage community several independent researchers are studying data retrieval protocols. In general, data retrieval protocols require some agreed upon processing of the data before storage so that when Alice requests her data, the process in which it is done incentives Alice to pay Bob and for Bob to give Alice her data. Based on the Filecoin whitepaper it seems Filecoin and the two papers listed below approach the problem differently. Full disclosure I am a co-author on the first one.

https://eprint.iacr.org/2019/541
https://eprint.iacr.org/2018/740