Hacker News Reader

Comment by hathathat | Hacker News Reader

They seem to have solved proof-of-storage, but the network can’t guarantee the available of the files you pay to store! A profitable strategy:

1. Set up a miner on AWS. You’ll only need a small machine as you’ll persist the data in S3.

2. Accept bids for storage, and use your free ingress bandwidth to copy the data into S3

3. Calculate and publish your proofs of storage so your Filecoin (held in escrow after your successful bid) is released.

4. Refuse all bids to access the content - egress bandwidth costs money!

5. Win! You’ll always be able to undercut other miners when bidding for storage as they have to bake in bandwidth costs in their bids, and you strategy is easily scalable (as you can pump as much data into S3 as you need - you’ll only need to get more machines to calculate more storage proofs).

View on HN

I think you're assuming some kind of broken strawman version of Filecoin. (Edit: This wasn't really justified, see below.) The price of retrieving data needs to be agreed ahead of time and nodes that refuse to provide data need to lose collateral. Ultimately there's also replication/erasure coding so that one node can't hold your data hostage (but it would be worrying if evil was a dominant strategy because then all the nodes might hold your data hostage at the same time).

(Also, for step 3 I think proofs of storage are supposed to be calculated continuously, not once. So you'd be constantly reading data from S3.)

I'm not sure why you say it's a strawman? The whitepaper[1] says that an ask order on the storage market is just (space, price) -- no mention of the cost to retrieve the data. Similarly, the storage market protocol (Figure 11) doesn't mention losing stake for failing to provide the data on demand (it only mentions losing stake for failing to post proofs).

[1] https://filecoin.io/filecoin.pdf

I admit that the concept of retrieval miners makes no sense to me since it seems like they would have to be the same as the storage miners. It is worrying that the whitepaper says "we must assume that there is always one honest Retrieval Miner"; you can't assume honesty without incentives.

In general, I don't take the Filecoin whitepaper too literally. There are a lot of aspects of it that will probably have to be changed. I think the Filecoin ICO (which I didn't participate in BTW) is more of a vote of confidence on the team, not any specific protocol.

Collaterals can be tricky. For how long is this collateral held? It could potentially be years until the data is retrieved.

Last I looked at FileCoin, you were going to need much more than a small machine to compute the proofs of storage, They seemed to be the main economic impediment to FileCoin as a competitive storage mechanism.

Have there been technical developments since the whitepaper?

Why bother even copying the file to S3? Just throw it away and then never serve it.

Because you need the files to do proof of proof-of-storage and get your coins (back).

But as the OP said there's currently no proof-of-will-to-distribute-storage so you can save money by just sending the proof-of-storages to the network and never actually provide bandwidth for the distribution of the stored data.

How many coins do you think they will give per token for filecoin?

You will get undercut because AWS storage is extremely expensive and nobody sane actually stores data with significant amount of traffic there. The outbound network traffic fees are enough to make your strategy unprofitable. Then there is also the fact that you're wastefully storing 3 redundant copies of an erasure coded piece of data when you could just store 3 erasure coded pieces of data directly without any redundancy.

What's most likely going to be profitable is buying crappy consumer HDDs inside external enclosures and shoving 60 of them into a single chassis. The reliability of the storage medium doesn't matter with something like filecoin. Node failure is not just an edge case. Filecoin has to account for it by using erasure coding to survive the loss of nodes.

Reply on news.ycombinator.com