Sia
Sia copied to clipboard
NebulousLabs
Renter uses outdated host settings during revision loop
BUG REPORT
Stack Trace or error message After changing download price from 0SC to 10SC I started seeing these error messages. It appears that old renters are being denied access to their files, and affecting my interaction score with them, because they are paying their contracted price of 0SC while my host rejects their payment. The host appears to be expecting the new 10SC price even from older, already contracted, renters.
host.log: https://gist.github.com/Bojak4616/26e961415b6ddf0bb007e0187486ab86
Expected Behavior Renters should be able to pay the price they agreed to during contract formation, not be denied downloads because of new pricing.
How to reproduce it (as minimally and precisely as possible) Change hosting price.
Environment
- Sia version: v1.3.2
- OS: Linux version 3.10.0-693.17.1.el7.x86_64 ([email protected]) (gcc version 4.8.5 20150623 (Red Hat 4.8.5-16) (GCC) ) #1 SMP
The renter is supposed to always use the most recent settings. Unfortunately the most recent settings are currently not exchanged when you download data but only when you scan the host again.
@ChrisSchinnerl Are you sure that the renter is supposed to always use the most recent settings? I would think the renter would use the agreed settings in the contract. If the host changes his settings during the contract, there will be a new negotiation during contract renewal leading to acceptance (or not). I think this is what @Bojak4616 also mentions in his bug report.
@nielscastien since we are operating in a trustless system we can't force the host to store new data, or give us access to our data if our agreed upon terms are no longer profitable to the host. So if for example the price of the coin goes down by 10% the host would increase its pricing by the same percentage. If that's not possible it would end up in a situation where it is incentivized to drop low price renters. Of course the same is valid in case the price of the coin goes up by 10%. In that case it is the host who needs to be able to decrease the pricing. Otherwise the renter might end up in a situation in which it is cheaper to simply upload the data to a more competitive host.
@ChrisSchinnerl Thanks for the clear explanation. I think I'm beginning to understand the concept better now.
This would be a good item for SiaTV and/or the Wiki as this impacts everybody that uses the system (except the miners). From the Wiki:
Contracts are locked in at whatever rate the host sets and the renter agrees upon at the beginning of the contract. If the price of Siacoin fluctuates significantly during the contract, the host will still receive the agreed upon amount of Siacoins upon successful completion of the contract, though the coins may be worth more or less in fiat at that time. The renter will not be affected, as they acquired their Siacoins and spent them when they were committed to the host at the beginning of the contract, and therefore before the fluctuation in price occurred.
@nielscastien The Wiki is correct too. The problem is that it's talking about something slightly different: the storage price. The storage price, like the upload and download price, is allowed to fluctuate during the contract period. However, once you upload some data to the host, the host has committed to storing that data for the entire contract period in exchange for a set price. So the renter might upload 1 TB for 1000 SC at the start of the contract period, and then later the host might change its storage price to 2000 SC, but it doesn't matter -- the data is already stored. In that sense, the host is indeed exposed to price fluctuation.
If the host can change the bandwidth price "on the fly" and apply that to existing contracts, the bandwidth price should be removed from host score as otherwise it enables a bit of cheating. The host can set bandwidth price to zero, get a score boost for that, get contracts and data, then increase the bandwidth price so downloads cost 100 times more than storage price. There is no "GoodForDownload" flag for contracts on the renter side.
@rprikulis if the host tries to pull a scam like that, the renter can detect it and never form contracts with them again. In other words, the renter is free to enforce a policy of never allowing hosts to change their prices. But we view this as overly restrictive, so currently the renter does not do this. Unfortunately, I don't think there is a clear best policy for price restriction. If you never let hosts increase their price, then hosts will be too exposed to volatility in the SC exchange rate. If you allow hosts to increase up to (e.g.) 5%, then hosts will simply jack their price up 5% immediately. You can try to devise more complex schemes, but ultimately I don't think it's possible to identify "cheating" with 100% accuracy. Probably the best we can do is hope that market forces drive hosts to offer the lowest possible prices. If the renter is keeping track of each host's average price over the duration of their contracts, it can replace the most expensive hosts with cheaper ones.
@lukechampine if the renter selects least expensive hosts for downloads first, it should be ok for both sides- the renter simply does not download from a host if there are cheaper alternatives. But there definitely should be no error/failing if only the bandwidth pricing has been increased and there are no cheaper alternatives. So the renter could be affected only if more than 2/3 of contracts alter (increase) their bandwidth pricing, that is a positive side effect of redundancy. And the hosts are incentivized to keep bandwidth prices competitive all time. Especially if that is applied to existing contracts and already uploaded data.
With the overdrive (turbo download) enabled the user intentionally gives the renter module green light for selecting more expensive hosts and the selection checking/sorting could be skipped to lower the latency.