Sia vs. Storj vs. MaidSAFE


  • admins

    Sia's primary goal is to provide decentralized, incentivized, byzantine fault-tolerant storage that is competitive with centralized alternatives (primarily Amazon S3, which powers Dropbox). Sia has a strong focus on being a product for enterprises, and has been working hard to design a flexible protocol that can be heavily optimized for the various use cases of cloud storage. We are confident that, above all of our competitors, Sia has the foundation necessary to be the fastest, most reliable, lowest cost, and most rewarding platform. We emphasize strong engineering and uncompromising technology.

    The other major players in this space are Storj and MaidSAFE. Our biggest advantage over these solutions is that we work, today. For the past year+ we have been quietly designing, implementing, and refining the core Sia codebase. We are not interested in promoting a flashy product that does not work or has gaping security vulnerabilities.

    • Sia supports on-blockchain smart contracts that require hosts to store files in order to get paid. Once the contract has been created, the host is guaranteed to get paid, even if the uploader never accesses the file. This contract also allows us to enforce penalties on hosts that go offline or lose data.
    • Storj is similar to Sia, but does not feature on-blockchain storage contracts. Instead, Storj offers a pay-as-you-go model where hosts are paid with some frequency by the users. If the users disappear or go offline, the host stops getting paid. Storj is still running test groups, and has not yet implemented a network where you can upload files.
    • MaidSAFE is a very ambitious project that goes beyond just decentralized storage. They also have a much softer focus on efficiency. Sia's network should be both cheaper for uploaders AND pay its hosts more, due to smarter redundancy management. MaidSAFE also does not yet have a working global network where you can upload and download files.
    • MaidSAFE uses a completely novel scheme for achieving consensus (not a blockchain). This scheme is not proof-of-work, and has not been reviewed anywhere near as extensively as the Bitcoin protocol.

    IPFS is frequently brought up as a potential competitor, but the goals, design, and approaches of IPFS make it a significantly different system that doesn't really fit in with Sia, Storj, and MaidSAFE.



  • There is a somewhat interesting, but dated, comparison of storage systems that somehow use a distributed approach at http://www.flud.org/wiki/SimilarSystems (which is, in turn, the site of an open source system of that sort, but a seemingly abandoned one).



  • Great comparison. I have been searching such application for my CCTV storage solution. Storj first came to my mind but the problem is it has a minimum of 10,000 SJCX that will be around $115 . Upon learning SiaCoin I immediately tested it and the beta looks promising. Looking forward for your official launch.



  • @jwiz168 Yeah, I don't get that money up-front thing with Storj. It seems just to be a trick to artificially inflate the value of Storjcoin (SJCX). In effect thus, it almost seems like an alternative Ponzi scheme in that the 'investment' made by new users increase the value of Storjcoin thus allowing current users to profit from their initial investment into SJCX. Also, isn't SJCX pre-mined? Seems like dangerous play to me...



  • from the flud page http://www.flud.org/wiki/SimilarSystems

    i know tahoe quite well that i am using

    tahoe is using erasure coding and not blockshain technology

    and is not offering financial incentives

    also tahoe have a very limited UI



  • Erasure coding and blockchains are not mututally exclusive, if that's what you mean with that "and not".
    In fact, Sia uses erasure coding too.



  • tahoe use erasure coding only not blockchain

    i am going a bit into sia sources, i see it is using reed solomonl erasue coding like tahoe



  • Really appreciate this comparison. I will be keeping an eye on it .Just one thing as per "...Sia has a strong focus on being a product for enterprises..." does that mean that the service wont be affordable for individuals i.e. students. Thanks


  • admins

    Sia should be affordable for students in the near term. We're not 100% sure how it's going to scale, but I've had a lot of good ideas recently. Especially if you are doing append-only data, we should be able to get that to scale very well, enabling a multitude of mutually distrusting parties to participate in a single on-chain transaction. There are also lightning-network style optimizations that we can do.

    So, while we are targeting enterprises, we are also looking to keep decentralized data affordable for the average consumer as well.



  • Wanted to respond directly to some questions:

    @jwiz168 said:

    Great comparison. I have been searching such application for my CCTV storage solution. Storj first came to my mind but the problem is it has a minimum of 10,000 SJCX that will be around $115 . Upon learning SiaCoin I immediately tested it and the beta looks promising. Looking forward for your official launch.

    So for your CCTV application you don't need 10k SJCX. You just pay for data storage as you use it. The 10k SJCX is only required for farmers, and those restrictions will be eased over time.

    @in-cred-u-lous said:

    @jwiz168 Yeah, I don't get that money up-front thing with Storj. It seems just to be a trick to artificially inflate the value of Storjcoin (SJCX). In effect thus, it almost seems like an alternative Ponzi scheme in that the 'investment' made by new users increase the value of Storjcoin thus allowing current users to profit from their initial investment into SJCX. Also, isn't SJCX pre-mined? Seems like dangerous play to me...

    If you read the Storj whitepaper's attack section you can see why we added this requirement to testing. While these decentralized storage networks are new anyone could spin up a Amazon cluster or botnet, store a bunch of files for a while, then drop them all. By adding this "bond" we make its really expensive on Storj. For Sia and Maidsafe, they have to scale really quickly and hope that someone doesn't want to spend a few hundred dollars to break the network in the early days.

    tldr; it costs money to try to "51%" attack the Storj network. as the network grows that cost will come down significantly



  • Directly responding to Taek above:

    • We discussed on-blockchain smart contracts with Taek here in Atlanta extensively. It is our opinion that this does not scale beyond 60k users(which is extremely limited) if used as the primary method. Therefore we go going with a more stateless model, where users and farmers(what you call hosts) are paid immediately and not bottlenecked by a blockchain.
    • This open ended in the contract. If you agree to be paid once a month, you get paid once a month. If you agree to paid every 10 minutes, you do. The user does not have to be online for the host to get paid, but it is preferable.
    • We both agree that MaidSAFE is very ambitious. If they succeed I think it would be great for all of us. Just not holding my breath on it happening soon.

    Some things we feel are important:

    • Things must be very simple to use for this to scale. Guess where we released a solid and stable GUI for DriveShare: https://i.imgur.com/dNkYA7y.png
    • Network choices should be made with data, which is why we focused on DriveShare first before offering data services. We have been tracking over 3 PB with over 1000 users. Puts us in a very good position as we get ready to release MetaDisk, which allows users to store data.
    • Sia is great, and Taek is a cool guy
    • Using the Bitcoin blockchain is key, its already robust and tested.

  • admins

    That's a handful of points, I'm going to respond to them in a semi-random order.

    A very important difference between Sia and Storj is that Stroj is pay-as-you-go. That means, at any point in time, you have no secruity about whether you are going to get your next payment, or whether the host is suddenly going to disappear. This is important for both the renter and the host.

    As the host, it's reasonable to assume that renters are not going to have great uptime. They might miss payments, or if you are renting data on a longer timescale, they might intentionally cheat you out of a payment. For example, a monthly payment schedule means that I can cheat the host by a full month worth of storage, which could be several dollars. Multiply that by 100 cheating renters, and the host has a significant revenue problem. To protect themselves, the hosts need to require short hosting cycles and even then there's no guarantee that their storage contracts will persist for the duration specified in the contract.

    The host also has nothing holding them to the contract. If the host gets a better offer - say, 10% more money - the optimal decision for the host to make is to drop the existing data and to take the contract worth more money. There is nothing in Storj that prevents this behavior, and there are no financial penalties that can be levied against the host to discourage this behavior. The network is relying on the good will of hosts to not leave.

    On Sia, the story is very different. All money is paid up-front and put into a file contract. The host is guaranteed to get paid for storing the data over a long timescale, regardless of the actions of the renter. And similarly, the host is guaranteed to not get paid if they lose the data. The renter doesn't need to be online to check. Furthermore, in Sia the host can put up collateral. If the renter is paying 10 SC into the file contract, the host can pay 30 SC into the file contract, which means at the end of the contract the host will either get paid 40 SC or 0 SC. This is significant incentive for the host keep the data. To make it profitable for the host to drop the contract, the next person would need to offer a payment that is 4x what the existing contract is worth. This can be compared to Storj, where it's worthwhile for the host to switch after any bump in price, even very small ones.

    It's important to remember that on a decentralized network, you are dealing with greedy, anonymous, fully untrusted hosts. You have no idea who is getting your data, what their motivations are, and what their timelines are. If a host knows they only care to store data for 6 weeks, but knows they can sell the data for more by advertising that they will keep it for 2 years, they can leave suddenly. On Sia, it is very expensive for a host to leave early. On Storj, there is no cost at all.

    Because hosts are anonymous, and because anyone can become a host, I think it makes sense to assume that profit seeking entities will try and take advantage of the system. Today, that's not much of an issue because there's not much profit to be made. But when there are thousands or tens of thousands of dollars flying around the network (or, in the case of the end-game, billions of dollars) there is much more advantage to an anonymous host trying to be manipulative. There is a clear incentive for cheating and it's easy to do so without getting caught. Decentralized systems make it easy to commit fraud successfully anywhere that fraud is possible.

    And the Storj model is vulnerable to many types of fraud. In general, this is my biggest complaint with the Storj network, and the Storj approach to doing things. I also recall there being vulnerabilities in the way that Stroj was doing capacity measurements on their network - figuring out how much free space a host has is actually a very difficult task, to the point that Sia decided to abondon it as a worthwhile tool. I haven't looked at the algorithm recently, but earlier versions of the algorithm were broken, such that a smart host could fairly easily lie about having 50x - 500x the amount of storage that they actually had. (further discussion of this matter should happen in another thread - it's likely to be a longer discussion that's highly technical)

    I'm not 100% what all Storj is using the blockchain for, but from what I remember they are having hosts chainpoint their uptime on the blockchain. Hosts can prove uptime by putting a series of storage proofs on the blockchain. I don't remember what other things Stroj was doing with the blockchain.

    On scaling: The current Sia model for uploading is going to support about 200,000 users at any volume of data. That's where we start to run out of steam. If users are comfortable paying for a year of storage in advance, we get a bump to about 1.5 million users. If we get protocol improvements that allow for safer bigger blocks, we can get to maybe 10 million users. And then we have this user-batching protocol we're working on which may allow us to get 10-100x improvements beyond that, putting us at 1 billion users in the optimal case. But those are all pretty big IFs. I feel confident that we can get to 200,000 users just fine, and that we have wiggle room for squeezing more scalability into the network beyond that. But yes, catering directly to consumers is going to be a tough problem for Sia. That's one of the reasons we're more enterprise focused. 200,000 enterprises is a LOT of data, and will work just fine on the Sia network.

    On tech: I do feel that the Sia technology is very good. We've had a network where you could upload and download files for 7 months now. While buggy, while slow, we've gained a lot of experience from watching real files move over the network, and it's strongly shaped our opinions about how the network should be designed. Storj does not have that right now. I have strong confidence in the engineering abilities of our team, and I have strong confidence in the architectural design of our daemon + protocols. I do feel that when it comes to security, reliability, renter-cost, host-revenue, and data throughput, Sia will be superior. From day one our goal has been to create a highly parallel, highly secure, highly fault tolerant, highly cost-competitive, highly efficient network, and I think our current prototype is demonstrating that we are on-track for hitting those goals. While the current prototype does not check all of those boxes, the reasons that it falls short are not architectural reasons, but rather an artifact of it being early software.

    In short, Sia is definitely my favorite platform, which is why I spend most of my waking energy working on it :). But it does make tradeoffs, and these tradeoffs are different from the tradeoffs that Storj makes. People who require high levels of trustlessness are likely to favor Sia, but the market will ultimately decide.


  • Global Moderator

    @Taek said:

    On scaling: The current Sia model for uploading is going to support about 200,000 users at any volume of data.

    Does that also imply any number of files (not file-contracts)?

    As with bitcoin, it may at one point not be feasible for individuals to sync the Sia blockchain and run their own nodes.

    Instead, we'll see 3rd parties stepping in and providing services on the blockchain. The Sia network and blockchain will become invisible to the end-users who will pay in fiat and upload with a simplified client. In that case, 200,000 users seems plenty.



  • @Taek said:

    A very important difference between Sia and Storj is that Storj is pay-as-you-go. That means, at any point in time, you have no security about whether you are going to get your next payment, or whether the host is suddenly going to disappear. This is important for both the renter and the host.

    This is not accurate. As I said before the host does not have to be online for payment to go through. The payment hubs, MetaDisk, or blockchain (if you really have to) can take care of that.

    As the host, it's reasonable to assume that renters are not going to have great uptime. They might miss payments, or if you are renting data on a longer timescale, they might intentionally cheat you out of a payment. For example, a monthly payment schedule means that I can cheat the host by a full month worth of storage, which could be several dollars.

    So you have two options. Don't choose a monthly timescale. Do 10 minute increments. Most you could loose is $0.000006 at S3 prices. In the scope of the 10,000 contracts you might have, it means absolutely nothing. Or you could just wait until we add a blockchain based enforcement later.

    Its clear to me there is a difference of focus. You protect the farmer. We protect the renter. If the farmer is gone for half the time, or refuse to actually transmit the file they still get paid under Sia. Yes they have to keep the file, but there is no incentive to have it easily accessible or available publicly.

    On Sia, it is very expensive for a host to leave early. On Storj, there is no cost at all.

    Incorrect, there is a cost for being a farmer on Storj in the first place. If you leave early you are going to lower your reputation, and perhaps even loose your bond.


  • admins

    Does that also imply any number of files (not file-contracts)?

    Correct, any number of files. The important part is the trust point. Sia supports (in its current protocol, assuming no advancements in the theory) between 10,000 and 10,000,000 unique trust points (less if the trust is refreshed frequently and spread over many hosts - 200 host setups with new contracts every week will limit the number, 8 host setups with new contracts every year will allow the number to be large - Sia's default settings will likely be around 200,000 total supported trust points).

    If multiple people trust eachother, they can access the network on a single trust point. Similarly, if you have many files, you can upload all of those files through a single trust point (because... presumably you trust yourself).

    This is not accurate. As I said before the host does not have to be online for payment to go through. The payment hubs, MetaDisk, or blockchain (if you really have to) can take care of that.

    How is that implemented? I don't understand what you mean by 'the host does not have to be online for payment to go through'. If the host is not online, ideally they are not getting paid. If the renter is not online, the host is not getting paid at all? Unless someone is somehow spending money for the renter, which means that the renter is trusting the person spending the money, and you are back to a centralized system. And, it's still pay-as-you-go. If you are using payment channels, money will not flow down them unless someone sends the money down the channel. You have no guarantees that the money is going to arrive, though you are storing the data. Until you get the money, you are storing that data for free and trusting that the other person will hold up their end of the deal.

    Do 10 minute increments.

    That works, and solves the problem I described. But if you are doing 10 minute increments, the renter is now required to be online all the time. If the renter experiences more than 10 minutes of downtime, the host assumes that the renter is gone forever (and if the host does not assume that the renter is gone forever, you're actually using an increment larger than 10 minutes). How is the host getting paid every 10 minutes if the renter doesn't have 100% uptime?

    Incorrect, there is a cost for being a farmer on Storj in the first place. If you leave early you are going to lower your reputation, and perhaps even loose your bond.

    What is the mechanism for losing the bond? How does the bond get placed, and what are the terms that cause the host to lose the bond? How are those terms enforced?

    You protect the farmer. We protect the renter.

    No, we protect both. In a pay-as-you-go model, there is no bond forcing the host to keep a file. Though, you've mentioned the possibility of the host losing a bond, you'll have to elaborate on how that works.



  • @jwiz168 you don't need to purchase 10K storj if you are a customer. Only for farming.



  • Our payment options and rankings:

    1. You pay and verify yourself in a time period both the renter and a farmer agree upon. This means you get paid instantly, or at least in a time period you agreed on.
    2. If you can't be online then you delegate it to a GVN, which is described in the Storj whitepaper near the end.
    3. Blockchain based Ethereum smart contract. (This is similar to Sia's method)

    We do this for a couple reasons. Taek please correct me by number if any of these are inaccurate.

    1. Farmers don't have to wait 2 weeks for a contract to pay out, you get paid the instant you provide service
    2. 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.
    3. 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.
    4. Not reliant on a single blockchain.

    What is the mechanism for losing the bond? How does the bond get placed, and what are the terms that cause the host to lose the bond? How are those terms enforced?

    So the protocol is designed so that you have enough information to make a judgement. The terms are completely adjustable between the farmer and renter. The enforcement is a Eth smart contract.

    No, we protect both. In a pay-as-you-go model, there is no bond forcing the host to keep a file. Though, you've mentioned the possibility of the host losing a bond, you'll have to elaborate on how that works.

    From my understanding Sia has no method or reward to verify that the file is retrievable. So if I store a file, and complete my Sia contract audits, I could just refuse to transfer the file (as its x2 the cost of storing the file) and still get paid.

    In the Storj system that farmer would be cut off immediately for poor service. On the other hand the renter might be offline for 10 minutes or an hour and I'll just wait. Not worth chasing thousands of a cents, since payment periods are so short.



  • Looks like some of these are described in a post here:
    http://forum.sia.tech/topic/94/upload-incentive/2

    Didn't know that you had a reputation system in place. Have any documentation on that?


  • admins

    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.


  • admins

    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.


Log in to reply