Sia vs. Storj vs. MaidSAFE
-
If you can't be online then you delegate it to a GVN, which is described in the Storj whitepaper near the end.
Using GVNs has a large number of potential problems with it, but one very important underspecification. You don't explain how the group of nodes is selected, and that's going to significantly impact the security of the strategy. Using N-of-N signatures to make payments is vulnerable to DoS attacks, which means that a single corrupt host in the group can block payments, meaning the host will not be paid and will therefore drop your data. On the other hand, depending on the selection process it may be entirely possible for an attacker to use some combination of Sybil attacks and choice-manipulation to get the entire set on N nodes, meaning that the whole balance can be stolen all at once. I will finish by saying that I think node selection would be a very difficult problem, and I don't think that GVNs are a secure way to manage payments.
Blockchain based Ethereum smart contract. (This is similar to Sia's method)
Not reliant on a single blockchain.
Has Storj added ethereum support? Also, how are you planning on implementing support for multiple blockchains? Does this mean that every client is going to be running multiple blockchain nodes? I also think that doing something like that would greatly increase the surface area for attacks, and is something I personally would not pursue. Would like so see some elaboration here about what you mean. Depending on the implementation, needing multiple blockchains could end up being a substantially worse position than needing a single, optimized-for-decentralized-storage blockchain.
Bandwidth is 2x the cost of storage. Because of the "pay as you go model" we can reward for bandwidth. Without a this model a farmer could loose out on 100x rewards for transferring a popular file.
The Sia protocol fully supports paid bandwidth, which may be available in our next release, and if not it will be available in the one following. Even more, Sia supports fully flexible bandwidth prices, meaning that hosts and renters can apply some simple rules to begin participating in efficient distributed load balancing.
Which system do you want to store your most important files on? One that checks every two weeks or one that checks every 10 minutes.
This is a question you've asked multiple times, yet you seem to keep ignoring the answer. Sia can perform online hosting checks at the same granularity as Storj. The blockchain penalty is not applied immediately, but this is in sharp contrast to Storj which cannot apply the blockchain penalty at all. It is disingenuous to suggest that a renter would have to wait 2 weeks on Sia to discover that their files were no longer available from a particular host, because a renter could easily check every 10 minutes or faster and, for sensitive files, could begin repairing immediately.
In the Storj system that farmer would be cut off immediately for poor service.
Cut off by the renter? That still does not help the renter if the renter needed access to those files. The host is not committed to the storage in any way. Because the model is pay-as-you-go, there is no opportunity cost to the host for leaving early.
Didn't know that you had a reputation system in place. Have any documentation on that?
It's coming in our new whitepaper. It's important to distinguish though, Sia does not have a global reputation system. As far as I'm aware, a global decentralized reputation system is not possible, or at least modern science doesn't understand how to do it. Reputation in Sia is maintained on a per-trust-sphere basis, which means that you never trust what someone else tells you about whether a host is reliable or not. You merely watch yourself and draw conclusions.
You did not answer one of my questions from before: How does Storj manage host bonds?
I'm sorry to say it but overall it seems like you are doing a lot of handwaving and glossing over implementation details which have a huge effect on the viability of some of the things you are proposing to do with Storj. When dealing with untrusted and Byzantine systems, the details end up being just as important as the high level concepts, and Storj in general doesn't seem to supply enough detail. Though I will admit, the Sia whitepaper also falls short fairly significantly, which is the major reason that we're in the process of writing another one.
-
Homogeneous solutions lead to Sybil attack vectors. Therefore we leave those kind of choices up the the contracts.
Using GVNs has a large number of potential problems with it, but one very important underspecification. You don't explain how the group of nodes is selected, and that's going to significantly impact the security of the strategy. Using N-of-N signatures to make payments is vulnerable to DoS attacks, which means that a single corrupt host in the group can block payments, meaning the host will not be paid and will therefore drop your data. On the other hand, depending on the selection process it may be entirely possible for an attacker to use some combination of Sybil attacks and choice-manipulation to get the entire set on N nodes, meaning that the whole balance can be stolen all at once. I will finish by saying that I think node selection would be a very difficult problem, and I don't think that GVNs are a secure way to manage payments.
When I get some time I'd like to write up a whitepaper that I think is an extension or better than GVNs. I like to call it "Dead Man Protocol." Essentially you have N nodes, some/any of which can trigger a blockchain audit. Fast, but also very byzantine tolerant.
Has Storj added ethereum support? Also, how are you planning on implementing support for multiple blockchains? Does this mean that every client is going to be running multiple blockchain nodes? I also think that doing something like that would greatly increase the surface area for attacks, and is something I personally would not pursue. Would like so see some elaboration here about what you mean. Depending on the implementation, needing multiple blockchains could end up being a substantially worse position than needing a single, optimized-for-decentralized-storage blockchain.
Since we settle quickly no need to add it anytime soon. Since we didn't make our own blockchain we don't need to run nodes. Bitcoin's works just fine.
Quick question: For Sia does the person storing data and/or the person farming need to run a blockchain node?
The Sia protocol fully supports paid bandwidth, which may be available in our next release, and if not it will be available in the one following. Even more, Sia supports fully flexible bandwidth prices, meaning that hosts and renters can apply some simple rules to begin participating in efficient distributed load balancing.
Can you point me to some documentation on this. Very curious.
This is a question you've asked multiple times, yet you seem to keep ignoring the answer. Sia can perform online hosting checks at the same granularity as Storj. The blockchain penalty is not applied immediately, but this is in sharp contrast to Storj which cannot apply the blockchain penalty at all. It is disingenuous to suggest that a renter would have to wait 2 weeks on Sia to discover that their files were no longer available from a particular host, because a renter could easily check every 10 minutes or faster and, for sensitive files, could begin repairing immediately.
So the renter would have to be online to do that check? Is the money refunded to the renter in that case?
Tell me a little bit more about the 10 minute checks. For example if the farmer goes offline for 30 minutes, who checks this and what penalties are imposed.
Be fun if we could get someone from MaidSAFE in here.
-
Can you point me to some documentation on [paid downloads]. Very curious.
Currently, there's not much documentation on how it works. When you create a file contract with a host, you also create a payment channel to the host. You can then use that payment channel to pay for downloads. More will be explained in our upcoming whitepaper rewrite.
Homogeneous solutions lead to Sybil attack vectors.
??? Can you explain that more, I do not think it is correct.
Quick question: For Sia does the person storing data and/or the person farming need to run a blockchain node?
If you want the full security and decentralization benefits, you need to run a full node. If you are a host, you need to run a full node. If you are a renter, you need to run a full node. You could do SPV, but then you are not getting full security.
So the renter would have to be online to do that check? Is the money refunded to the renter in that case?
Tell me a little bit more about the 10 minute checks. For example if the farmer goes offline for 30 minutes, who checks this and what penalties are imposed.
The renter would need to be online to do the check, yes. If the renter is not online though, they already will not know when a host is offline. If a host is online every time that the renter is online, then from the perspective of the renter the host is perfectly acceptable.
Refunding money to the renter is actually a dangerous position for hosts to be in. If I create a $5000 file contract, and I know that I can get the money refunded by knocking the host offline, then I've got a strong incentive to DDOS the host and make sure that the host is unable to submit the storage proof, and make sure that the host is unable to provide proofs to the blockchain. It's bad incentive alignment. The default settings of Sia do not have the renter getting refunded under any circumstances, because of this incentive mis-alignment. The host can only receive penalties (in the default configuration - the protocol supports renter refunds but I think that it's a dangerous thing for a host to agree to, especially for long term file contracts or for high value / large file contracts).
If a host is offline when the renter tries to perform an uptime check, the host is penalized in the renter's database. The renter will be less likely to select that host again, because the renter has strict requirements about uptime. The host can still get paid for the file contract if they come back online, but they will be losing a lot of potential future revenue because nobody will trust them.
-
If it became apparent that hosts were doing abusive witholding attacks (accepting storage contracts, then going offline until a storage proof was needed), we could extend the protocol to support 'surprise' storage proofs that would need to go on-chain. But this adds complexity, and I really don't forsee it being an issue. The selection penalties that hosts face for going offline are already severe, it should be severe enough to prevent this kind of behavior in the host. It's not profitable.
-
@Taek "As far as I'm aware, a global decentralized reputation system is not possible, or at least modern science doesn't understand how to do it."
I believe morphis uses a decentralized reputation system. Or atleast i know it was/is being implemented for the decentralized discussion system once its done. You should check out its code
Sidenote, its surprising that this doesn't this forum force https when registering.
-
Sia's sia note and siacon design is much better than Storj.
Let's see which storage will be faster, more stable.
-
@Taek "As far as I'm aware, a global decentralized reputation system is not possible, or at least modern science doesn't understand how to do it."
I thought about it a lot more, and I now have some good ideas for places to get started. It's not a problem we intend to solve in the next year, but maybe in the next two we'll be able to put in something that resembles a reliable decentralized automated reputation system.
-
"but the goals, design, and approaches of IPFS make it a significantly different "
how, in what ways?
-
@sonicman said in Sia vs. Storj vs. MaidSAFE:
"but the goals, design, and approaches of IPFS make it a significantly different "
how, in what ways?
-
Hi Taek,
Nice product and thanks for the comparison.
In this news, Storj is going for Ethereum:
http://www.coindesk.com/storj-migrate-decentralized-storage-service-ethereum-blockchain/Seems that brings 2 advantages to them:
- make up the lack of smart contract for Storj
- ether is widely used and many businesses may build on Ethereum
I have Ether and Siacoin, and am familiar with the system. But for most of people, using Siacoin to pay and get-paid may be a bit of inconvenient.
Do you have any thought about this?
-
Yeah, I just saw that too on Storj's recent blog post:
Three weeks ago we [Storj] announced our migration from Counterparty to the Ethereum platform. When we first considered making the move, we were primarily concerned with providing an improved user experience via access to better wallets and tools.
- Storj: New Protocol, New Opportunities (Apr 14th, 2017)
http://blog.storj.io/post/159566947133/storj-new-protocol-new-opportunities
It would be nice to have more wallet options for Sia, especially mobile wallets. But this looks like it could be a ways down the road.
What stood out to me more though was this section of the same blog:
Dead Simple File Storage - Hundreds of people have requested this, and we’re excited to make this dream come true. For the past several months we’ve been working with a partner with a massive install base to create a graphical user interface for Storj. We expect to announce this partnership very soon.
So far only Sia has a GUI for clients. I'll be interested to see how the Storj GUI looks and performs. Still think I'll like Sia best.
- Storj: New Protocol, New Opportunities (Apr 14th, 2017)
-
So far only Sia has a GUI for clients. I'll be interested to see how the Storj GUI looks and performs. Still think I'll like Sia best.
Knowing them, it'll probably have pretty good design. But, I think really important to distinguish (at least at this point) that Storj is not a decentralized or trustless platform. If the Storj company were to disappear, hosts would stop getting paid, and most users would be unable to recover their files. The fact that Storj is a required middleman for any of the payouts to work should be a huge red flag.
It would be nice to have more wallet options for Sia, especially mobile wallets. But this looks like it could be a ways down the road.
We are more focused on getting the core platform running better. Mainly, we want to see
- ability to delete local files after uploading
- ability to restore files from a backup you made months ago
- ability to share files between Sia users
After we have those things, we'll take a step back and decide what the next moves are.
-
Storj is not a decentralized or trustless platform.
Yeah, I noticed that too and didn't like that about Storj.
We are more focused on getting the core platform running better.
Yes, the points you listed are far more urgent. Wallets can wait :)
-
Also check this link: https://coinjoker.com/sia-storj-maidsafe-comparing-distributed-decentralized-storage-options/
-
...not to forget the newest kid on the block, FileCoin and it's massie ICO:
https://www.coindesk.com/257-million-filecoin-breaks-time-record-ico-funding/
-
I would very much like to hear your latest news about this topic
